Requirements Analysis
Contents
What
The process of capturing the requirements for the system-to-be.
How
The dish
Requirements
Ingredients
Process
Initially it may be a good idea just to capture the requirements as individual requirements using the EARS Requirement Capture technique.
As the General Analysis progress try to organise the captured requirements into groups as mentioned below in the Why section.
After organising the requirements assign unique ID's to each requirement.
The terms used is important.
- "Shall" - the word shall determines a requirement that are demanded to be implemented
- "Will" - statements containing will identifies a future happening
- "Must" - requirements identifies strong wishes from the customer, but not requirements
- "To be", "is to be", "are to be", "should", and "should be" shall usually not be used in requirements as they identifies considered capabilities of the system-to-be
By having the customer answer the questions posed in the following listing a deeper knowledge can be achieved:
- Where will the system be used?
- How will the system accomplish its mission objective?
- What are the critical system parameters to accomplish the mission?
- How are the various system components to be used?
- How effective or efficient must the system be in performing its mission?
- How long will the system be in use by the user?
- What environments will the system be expected to operate in an effective manner?
Why
Requirements are the specification that determines what the system-to-be must conform to in order to fulfil the customers needs or wishes to the system-to-be. I.e. the customers needs are transformed into requirements for the system-to-be enabling the system-to-be to fulfil the needs.
While working with the other activities in the General Analysis part requirements emerge and should be captured promptly.
The initial requirements can be located in the artefacts produced in the PreProject phase. A story contains a lot of implicit requirements, the Rich Picture may embed requirements, etc.
Very often customers cannot present a detailed set of specifications of the system-to-be, but rather inform the developer how the system-to-be is expected to work and react in an unstructured manner. The developer must transform these expectations into a more formal description setting up exact requirements to the system-to-be.
We have to realise that it is a complicated and iterative process to identify the customer's needs. Especially the software can be highly abstract reasoning which might be difficult to understand for the customer. A process has input data, activity and output data. The pattern to locate the exact requirements is therefore:
- Input data: The customer's description of his vision, his needs and the concept for the project.
- Activity: Run through these activities repeatedly: Capture Requirements -> Analyse Requirements -> Specify Requirements -> Verify Requirements
- Output data: The result from the process will be a description of the exact requirements.
Requirements can be depicted in a SysML diagram suited for this purpose. Related requirements can be collected in packages. Each package contains a separate SysML diagram with the specific requirements.
Packages with requirements
One package with an incomplete requirements diagram
Requirements can be grouped into related requirements specifying different sides of the product.
Requirement types
Below is a quite comprehensive list of requirements types or grouping. Not all requirement types are relevant to a particular project.
Customer Requirements / Customer needs / User Needs
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and Measures Of Effectiveness and Measures Of Suitability (MOE/MOS). This type of requirements are typically expressed in a informal way and represents the customers expectations to the system-to-be. It is these requirements that must be transformed into requirements to system-to-be enabling it to fulfil the customers needs.
Behavioural Requirements
Behavioural requirements explain what has to be done by identifying the necessary behaviour of a system.
Functional Requirements
Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the top-level functions for functional analysis.
Non-functional Requirements
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviours.
Performance Requirements
The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.
Architectural Requirements
Architectural requirements explain what has to be done by identifying the necessary system architecture of a system.
Structural Requirements
Structural requirements explain what has to be done by identifying the necessary structure of a system.
Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.
Derived Requirements
Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.
Allocated Requirements
A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.
Source Types of Requirements as of 2011 02 27
Typical used Reuqirement Types
It is typical to at least include
- Functional Requirements ("system shall do <requirement>")
- Non-functional Requirements ("system shall be <requirement>")
- Behavioural Requirements ("how the system shall react")
- Performance Requirements ("how well does it have to be done")
from the list above, but select carefully according to the particular project.
Verification
Refer to Product Acceptance and Verification Recommendations in order to get information about how to verify the requirements. It can be a good idea to specify the verification at the same time as the requirements are written. If it is hard to write the verification it can be caused in an inadequate specified requirement.
Example
In a robotic control systems these requirements (partly) specifies the vehicle motion:
