Software Requirements Analysis with Example
Charles Moore
⚡ Smart Summary
Software requirements analysis breaks stakeholder needs into functional and non-functional statements, ranks them at business, architectural, and system levels, then checks each one against quality attributes to guarantee a testable, traceable, prioritised specification.
A software requirement is a functional or non-functional need that must be implemented in the system. Functional means providing particular service to the user.
For example, in the context of a banking application, the functional requirement is that when a customer selects “View Balance” they should be able to view their latest account balance.
A software requirement can also be non-functional, such as a performance requirement. For example, a non-functional requirement might state that every page of the system should load for users within 5 seconds.
So, basically software requirement is a
- Functional or
- Non-functional
need that has to be implemented into the system. Software requirements are usually expressed as statements.
Types of Requirements
Business requirements: These are high-level requirements taken from the business case for the project. For example, a mobile banking service system provides banking services to Southeast Asia. The business requirement decided for India is account summary and fund transfer, while for China it is account summary and bill payment.
| Country | Company providing Banking Functionalities or services |
|---|---|
| India | Account Summary and Fund Transfer |
| China | Account Summary and Bill Payment |
Architectural and Design requirements: These requirements are more detailed than business requirements and drive solution architecture. They determine the overall design required to implement the business requirement. For an educational organisation, typical architectural and design use cases include login, course detail, and enrolment. The requirement would be as shown below.
| Banking use case | Requirement |
|---|---|
| Bill Payment | This use case describes how a customer can login into net banking and use the Bill Payment Facility. The customer can see a dashboard of outstanding bills for registered billers. The customer can add, modify, and delete a biller detail. The customer can configure SMS and email alerts for different billing actions. The customer can view a history of past paid bills. The actors starting this use case are bank customers or support personnel. |
System and Integration requirements: At the lowest level, we have system and integration requirements. It provides a detailed description of every requirement. It can be captured as user stories written in everyday business language. The requirements contain abundant detail so that developers can begin coding. The Bill Payment module example below shows the requirement for adding a biller.
| Bill Payment | Requirements |
|---|---|
| Add Billers | Utility Provider Name, Relationship Customer Number, Auto Payments – Yes/No, Pay Entire Bill – Yes/No, Auto Payment Limit – Do not pay if Bill is over specified amount |
Sometimes for a project you might not receive any requirements or documents to work with. Even then, there are other sources of requirement information that you can rely on to base your software or test design. The other sources of requirements you can rely on are listed below.
Other Sources of Requirements
- Knowledge transfer from colleagues or employees already working on that project
- Discuss the project with the Business Analyst, product manager, project lead, and developers
- Analyse the previous version of the system already implemented
- Analyse older requirement documents from the project
- Review past bug reports; some bug reports are converted into enhancement requests that may be implemented in the current version
- Check the installation guide, if available, to see what installations are required
- Analyse the domain or industry knowledge the team is trying to implement
Whichever source of requirements you use, document them in a shared format and have them reviewed by experienced team members.
How to Analyze Requirements
Consider the example of an educational software system where a student can register for different courses.
Let us study how to analyse the requirements. Each requirement must maintain a set of standard quality attributes, which include the following:
- Atomic
- Uniquely identified
- Complete
- Consistent and unambiguous
- Traceable
- Prioritized
- Testable
The following table illustrates each attribute with three columns:
- The first column indicates- “requirement quality”
- The second column indicates- “bad requirement with some problem”
- The third column shows the same requirement “converted into a good requirement”.
| Requirement Quality | Example of bad requirement | Example of good requirement |
|---|---|---|
| Atomic | Students will be able to enroll to undergraduate and post graduate courses | Students will be able to enroll to undergraduate courses. Students will be able to enroll to post-graduate courses |
| Uniquely identified | 1- Students will be able to enroll to undergraduate courses. 1- Students will be able to enroll to post-graduate courses | Course Enrolment. Students will be able to enroll to undergraduate courses. Students will be able to enroll to post-graduate courses |
| Complete | A professor user will log into the system by providing his username, password, and other relevant information | A professor user will log into the system by providing his username, password and department code |
| Consistent and unambiguous | A student will have either undergraduate courses or post-graduate courses but not both. Some courses will be open to both under-graduate and post-graduate | A student will have either under-graduate or post graduates but not both |
| Traceable | Maintain student information-mapped to BRD req.ID? | Maintain student information-Mapped to BRD req ID 4.1 |
| Prioritized | Registered student-Priority 1. Maintain User Information-Priority 1. Enroll courses-Priority 1. View Report Card-Priority 1 | Register Student-Priority 1. Maintain User Information-Priority 2. Enroll courses-Priority 1. View Report Card-Priority3 |
| Testable | Each page of the system will load in an acceptable time-frame | Register student and enrol courses pages of the system will load within 5 seconds |
Let us understand each of these attributes in more detail, starting with Atomic.
Atomic
Every requirement should be atomic, meaning it must be at the lowest level of detail and cannot be broken down further into components. The following examples compare atomic and non-atomic requirements.
Continuing with the education-domain system example: Here, the bad requirement is “Students will be able to enroll to undergraduate and post graduate courses”. This is a bad requirement because it is not atomic — it mixes two different entities, undergraduate and post-graduate courses. The corresponding good requirement separates it into two requirements. One requirement covers enrolment in undergraduate courses, and the other covers enrolment in post-graduate courses.
Uniquely Identified
The next quality attribute is unique identification. In the bad example, two separate requirements share the same ID#1. If a team references a requirement by its ID, it becomes unclear which of the two is meant. The good requirement re-groups them under Section 1 — Course Enrolment, with sub-requirements 1.1 (enrolment to undergraduate courses) and 1.2 (enrolment to post-graduate courses).
Complete
Every requirement should be complete. For example, here the bad requirement says a “professor user will log into the system by providing his username, password and other relevant information”. “Other relevant information” is vague. A complete requirement lists the exact fields, such as department code, that the professor must provide.
Consistent and Unambiguous
Every requirement should be consistent and unambiguous. In the bad example, one requirement states “A student will have either undergraduate courses or post-graduate courses but not both”, while another states “Some courses will be open to both undergraduate and post-graduate students”.
The first requirement implies courses are split into two exclusive categories, but the second requirement contradicts it by opening some courses to both groups.
The good requirement resolves the conflict by stating clearly that every course is marked either as undergraduate or post-graduate, and a student can only enrol in courses of one category.
Traceable
Every requirement must be traceable because requirements exist at multiple levels: business, architectural and design, and system and integration.
When you convert a business requirement into architectural and design requirements, or architectural and design requirements into system and integration requirements, traceability must be preserved. Every business requirement should map to one or more architectural and design requirements. In the bad example “Maintain student information – mapped to BRD req ID?”, the requirement ID is missing.
The good requirement records the same statement but explicitly maps to BRD requirement ID 4.1. Every requirement must carry a traceability mapping. System and integration requirements should also map to the code that implements them and to the test cases that verify them.
Traceability therefore runs end-to-end across the project.
Prioritized
Every requirement must be prioritised so that the team knows what to implement first and what can wait. In the bad example, Register Student, Maintain User Information, Enrol Courses, and View Report Card are all set to Priority 1. Everything cannot be Priority 1, so the requirements must be ranked realistically. The good example gives Register Student and Enrol Courses the highest Priority 1, Maintain User Information Priority 2, and View Report Card Priority 3.
Testable
Every requirement should be testable. The bad example, “each page of the system will load in an acceptable time frame”, is not testable for two reasons. First, “each page” can mean dozens of pages, which balloons the testing effort. Second, “acceptable time frame” is undefined — acceptable to whom, and against what benchmark? The good requirement fixes both problems by naming the specific pages (“register student and enrol courses pages”) and setting a measurable target of 5 seconds.
