The requirements phase is one of the most critical phases of software engineering. Studies show that the top problems in the software industry are due to poor requirements elicitation, inadequate requirements specification, and inadequate management of changes to requirements. Requirements provide the foundation for the entire life cycle, as well as for the software product. Requirements also provide a basis for planning, estimating, and monitoring. Requirements are based on customer, user, and other stakeholder needs and design and development constraints.
The development of requirements includes elicitation, analysis, documentation, verification, and validation. Ongoing customer validation of the requirements to ensure the end products meet customer needs is an integral part of the life-cycle process. Customer validation can be
accomplished via rapid prototyping and customer-involved reviews of iterative and final software requirements.
The software requirement specification document has to satisfy two audiences The first audience is the user or the client, which in many cases, the user isn’t technical. User requirements are exactly what the user wants the solution to do in the user’s language. They may not able to explain clearly their needs But we still need to provide some sort of information that explains what the system will do, so that the user is relatively assured that they get, in the end, what the client is paid for and it actually does what the user or client wanted them to do.
The second audience is the developing team. We also need to provide enough detail to allow the people making the solution, making the code know what the system should and shouldn’t do. System spec is the usually more precise or constraining statement of how the system will meet the user requirements. This is still what the solution will do, not how, but it’s how the system will
meet the requirement. Software design then takes this requirement specification and details how. Which modules will be constructed? Will it be object-oriented design and development? How do we make it happen?
Non-functional requirements are requirements that don’t specify what the system will do, but rather how the system will perform the behaviors. Many of them revolve around process or quality attributes you’re seeking to instill in a project. They can be classified into three categories: Product, organization, and external. Product requirements that are non-functional talk about specific behavior. This is often in the form of protocol requirements, encodings, or encryption requirements, that sort of thing. They are requirements on the product itself. Software quality is also something that takes on importance at the very beginning. Security, performance, usability.
Organizational requirements are those that are defined by the company. Company standards, your development team’s code style requirements, even the development process itself like using Scrum could be defined as something like this. Process requirements may be things like mandating a particular case system, that is, a computer-assisted software engineering tool like Microsoft Project or Jira, a bug-tracking software. Or it might have to do with the programming language the team will be using or the development method.
And then external constraints are a big factor especially in regulated industries. When the FAA says you have to use this development process or meet these code coverage testing metrics,
that’s all there is to it.
WRSPM Reference Model or The World Machine Model
WRSPM Model is a reference model of how we understand problems in the real world. It helps to understand the difference between the requirement and the specification. Requirements are always in the problem domain. It is all about what the users want to do in order to solve some problems that they have.
W — is the world assumptions, that we know are true. They have an impact on our system and on our problem domain. These things everyone takes for granted, and they are one of the most difficult parts to capture.
R — is the requirements. This is the user’s language understanding of what the user wants from the solution. For example, users want to withdraw money. The ATM is the solution.
S—is the specification. It is the interface between how the system will meet those requirements. It is written in system language that says in plain English what the system will do. The specification is how the system meets the requirements. For example, in order to withdraw money from the ATM, you have to insert your card, insert PIN-number, etc. Those are the things user doesn’t care about. The user wants to get money.
P—is the program. It is what software developments will write. The program will meet the specifications to provide the user goal for requirements. The program has all the code, underlying frameworks, etc.
M—the machine. It is the hardware specification. For example, it includes the roller for distributing money, the lock box etc.
Eh — are the elements of the environment that are hidden from the system. These are parts of the environment that the user wants. For example, the card.
Ev—are the elements of the environment that are visible to the system. For example, the data generated, when you read a mag strip on the card and the entered PIN number.
Sv—are the elements of the system that are visible in the environment. For example, the button, the information on the screen.
Sh—are the elements of the system that are hidden from the environment. For example, the roller inside the machinery that the user can’t actually see, making sure that the machinery gets the approval number from the bank before distributing money.
The Software Requirements Specification details the software performance, interface, and operational and quality assurance requirements for each computer software configuration items (CSCI). When writing the SRS, it is important to capture specific, key information. Because requirements change and evolve over the life of the project, the SRS is typically revised as the project progresses.
- Product scope: The scope should relate to the overall business goals of the product, which is especially important if multiple teams or contractors will have access to the document. List the benefits, objectives, and goals intended for the product.
- Product value: Why is your product important? How will it help your intended audience? What function will it serve, or what problem will it solve? Ask yourself how your audience will find value in the product.
- Intended audience: Describe your ideal audience. They will dictate the look and feel of your product and how you market it.
- Intended use: Imagine how your audience will use your product. List the functions you provide and all the possible ways your audience can use your product depending on their role. It’s also good practice to include use cases to illustrate your vision.
- Definitions and acronyms: Every industry or business has its own unique acronyms or jargon. Lay out the definitions of the terms you are using in your SRS to ensure all parties understand what you’re trying to say.
- Table of contents: A thorough SRS document will likely be very long. Include a table of contents to help all participants find exactly what they’re looking for.
2. System requirements and functional requirements
Functional requirements break down system features and functions that allow your system to perform as intended.
- If/then behaviors
- Data handling logic
- System workflows
- Transaction handling
- Administrative functions
- Regulatory and compliance needs
- Performance requirements
- Details of operations conducted for every screen
Consider the following when capturing functional requirements: (NASA)
- Validity checks on the inputs.
- Exact sequence of operations.
- Responses to abnormal situations, including:
- Communication facilities.
- Error handling and recovery.
- Effect of parameters.
- Relationship of outputs to inputs, including:
- Input/output sequences.
- Formulas for input to output conversion.
- Relevant operational modes (nominal, critical, contingency).
3. Required states and modes
If the software “is required to operate in more than one state or mode having requirements distinct from other states or modes … identify and define each state and mode. Examples of states and modes include idle, ready, active, post-use analysis, training, degraded, emergency, backup, launch, testing, and deployment. … If states and/or modes are required, each requirement or group of requirements in this specification should be correlated to the states and modes. The correlation may be indicated by a table … an appendix … or by annotation of the requirements …”
4. External interface requirements
External interface requirements cover all inputs and outputs for the software system and expand on the interfaces generally described in the system overview. When capturing requirements for external interfaces, consider including interfaces to items such as test equipment or transportation systems.
External interface requirements are types of functional requirements that ensure the system will communicate properly with external components, such as:
- User interfaces: The key to application usability that includes content presentation, application navigation, and user assistance, among other components.
- Hardware interfaces: The characteristics of each interface between the software and hardware components of the system, such as supported device types and communication protocols.
- Software interfaces: The connections between your product and other software components, including databases, libraries, and operating systems.
- Communication interfaces: The requirements for the communication functions your product will use, like emails or embedded forms.
Embedded systems rely on external interface requirements. You should include things like screen layouts, button functions, and a description of how your product depends on other systems.
Note that interface specifications may be captured in a separate interface requirements document; in that case, reference to the separate document needs to be included in the SRS.
5. Internal interface requirements
Internal interface requirements can cover interfaces internal to the software (i.e., interfaces between functions), if those are not left to the design phase. Note that software design interface specifications are captured in an Interface Design Description, which needs to be referenced in the SRS.
When capturing internal interface requirements, information such as that noted above for external interface requirements applies, as appropriate.
6. Internal data requirements
internal data requirements define the data and data structures, e.g., files, databases, that are part of the software. Internal data requirements include information such as:
- Data types.
- Modes of access, e.g., random, sequential.
- Size and format.
- Units of measure.
If a database is used, consider capturing the following requirements:
- Types of information used by various functions.
- Frequency of use.
- Accessing capabilities.
- Data entities and their relationships.
- Integrity constraints.
- Data retention requirements.
7. Non-functional requirements (NRFs)
The most common types of NFRs are called the ‘Itys’. They are:
- Security: What’s needed to ensure any sensitive information your software collects from users is protected.
- Capacity: Your product’s current and future storage needs, including a plan for how your system will scale up for increasing volume demands.
- Compatibility: The minimum hardware requirements for your software, such as support for operating systems and their versions.
- Reliability and availability: How often you expect users to be using your software and what the critical failure time is under normal usage.
- Scalability: The highest workloads under which your system will still perform as expected.
- Maintainability: How your application should use continuous integration so you can quickly deploy features and bug fixes.
- Usability: How easy it is to use the product.
Other common types of non-functional requirements include performance, regulatory, and environmental requirements.
8. Safety requirements
While the SRS is not required to have a specific section that addresses the safety requirements, safety requirements are to be included in the SRS and designated (marked) as safety requirements.
“Software safety requirements are required to carry a unique identification or tag for traceability purposes. A way to mark and trace these requirements throughout the development and operational phases is needed in order to enable assessment of impacts and changes to the requirements. The unique identification or tag can be a special section in the requirements document, or a flag beside the requirement, or within a database. The method of identification is not important as long as it can be used for traceability and assessment.”
Software safety requirements “are derived from the system safety requirements, standards, program specification, vehicle or facility requirements, and interface requirements.”
The software technical requirements definition process is used to transform the baselined stakeholder expectations into unique, quantitative, and measurable technical software requirements that can be used for defining a design solution for the software end products and related enabling products. This process also includes validation of the requirements to ensure that the requirements are well-formed (clear and unambiguous), complete (agrees with customer and stakeholder needs and expectations), consistent (conflict free), and individually verifiable and traceable to a higher-level requirement. Recommended content for a software specification can be found in NASA-HDBK-2203.
References and Resources also include: