Difference between revisions of "Requirements Analysis"
(→Requirement types) |
(→Requirement types) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 20: | Line 20: | ||
'''Process''' | '''Process''' | ||
| − | Initially it may be a good idea just to capture the requirements as individual requirements using the [[EARS Requirement Capture]] technique. | + | 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 | + | As the General Analysis progresses, 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. | + | After organising the requirements, assign unique ID's to each requirement. |
| − | The terms used | + | The terms used are important: |
| − | * "Shall" - the | + | * "Shall" - the verb 'shall' states that a requirement ''must'' be implemented |
| − | * "Will" - | + | * "Will" - a statement containing 'will' identifies a future happening |
| − | * "Must" - requirements | + | * "Must" - requirements identify strong wishes from the customer, but not requirements |
| − | * "To be", "is to be", "are to be", "should" | + | * "To be", "is to be", "are to be", "should" and "should be" are usually not used in requirements as they identify 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: | + | By having the customer answer the questions posed in the following listing, a deeper knowledge can be achieved: |
* Where will the system be used? | * Where will the system be used? | ||
| Line 42: | Line 42: | ||
* What environments will the system be expected to operate in an effective manner? | * What environments will the system be expected to operate in an effective manner? | ||
| + | To locate the needs, you have to listen carefully to the customer's storytelling. A good tool is to draw a Rich Picture to get an understanding of the functionality. Then you analyse the information to get a structured picture of the problem. This analysis may include Preliminary Use Cases, System Definition and even Prototyping. Then you make a description and present it to the customer in order to secure that you have understood his needs correctly. You may have to go through this process several times before you are able to locate all the exact requirements. | ||
| + | |||
| + | It is important that the requirements are: | ||
| + | |||
| + | 1. unambiguous | ||
| + | |||
| + | 2. complete | ||
| + | |||
| + | 3. consistent | ||
| + | |||
| + | 4. correct | ||
| + | |||
| + | 5. measurable & testable | ||
| + | |||
| + | 6. changeable | ||
| + | |||
| + | 7. traceable | ||
| + | |||
| + | 8. documented | ||
| + | |||
| + | 9. actionable | ||
| + | |||
| + | 10. defined to a level of detail sufficient for system design. | ||
| + | |||
| + | in order to make the verification and product accept easy and without conflicts. | ||
| + | |||
| + | See [http://en.wikipedia.org/wiki/Requirement] for a more detailed explanation. | ||
=Why= | =Why= | ||
| − | Requirements are the specification that determines what the system-to-be must conform to in order to fulfil the | + | Requirements are the specification that determines what the system-to-be must conform to in order to fulfil the customer's needs or wishes to the system-to-be, i.e. the customer's 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. | + | 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 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 | + | 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 for 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: | + | 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. | * Input data: The customer's description of his vision, his needs and the concept for the project. | ||
| Line 61: | Line 88: | ||
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. | 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Requirements can be grouped into related requirements specifying different sides of the product. | Requirements can be grouped into related requirements specifying different sides of the product. | ||
| Line 74: | Line 93: | ||
==Requirement types== | ==Requirement types== | ||
| − | Below is a quite comprehensive list of requirements types or grouping. Not all requirement types are relevant | + | Below is a quite comprehensive list of requirements types or grouping. Not all requirement types are relevant in all project types. |
| − | '''Customer Requirements''' / '''Customer | + | '''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 | + | Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints and '''M'''easures '''O'''f '''E'''ffectiveness and '''M'''easures '''O'''f '''S'''uitability (MOE/MOS). This type of requirements is typically expressed in a informal way and represents the customer's expectations to the system-to-be. It is these requirements that must be transformed into requirements for the system-to-be enabling it to fulfil the customer's needs. |
'''Behavioural Requirements''' | '''Behavioural Requirements''' | ||
| Line 94: | Line 113: | ||
'''Performance Requirements''' | '''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 | + | 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 characterised 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''' | ||
| Line 106: | Line 125: | ||
'''Design Requirements''' | '''Design Requirements''' | ||
| − | The | + | 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''' | '''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. | + | 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''' | '''Allocated Requirements''' | ||
| Line 130: | Line 149: | ||
'''Verification''' | '''Verification''' | ||
| − | Refer to [ | + | Refer to [[Product Acceptance]] and [[Verification]] 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 difficult to write the verification, it may be due to an inadequately specified requirement. |
| + | |||
| + | A thorough explanation of the requirements capture process can be found through [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.5404&rep=rep1&type=pdf this link] | ||
=Example= | =Example= | ||
| − | + | [[Image:Requirements.png|600px]] | |
| − | [[Image: | + | '''Packages with requirements''' |
| + | |||
| + | [[Image:RequirementsEx.png|600px]] | ||
| + | |||
| + | '''One package with an incomplete requirements diagram''' | ||
Latest revision as of 08:23, 21 September 2015
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 progresses, 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 are important:
- "Shall" - the verb 'shall' states that a requirement must be implemented
- "Will" - a statement containing 'will' identifies a future happening
- "Must" - requirements identify strong wishes from the customer, but not requirements
- "To be", "is to be", "are to be", "should" and "should be" are usually not used in requirements as they identify 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?
To locate the needs, you have to listen carefully to the customer's storytelling. A good tool is to draw a Rich Picture to get an understanding of the functionality. Then you analyse the information to get a structured picture of the problem. This analysis may include Preliminary Use Cases, System Definition and even Prototyping. Then you make a description and present it to the customer in order to secure that you have understood his needs correctly. You may have to go through this process several times before you are able to locate all the exact requirements.
It is important that the requirements are:
1. unambiguous
2. complete
3. consistent
4. correct
5. measurable & testable
6. changeable
7. traceable
8. documented
9. actionable
10. defined to a level of detail sufficient for system design.
in order to make the verification and product accept easy and without conflicts.
See [1] for a more detailed explanation.
Why
Requirements are the specification that determines what the system-to-be must conform to in order to fulfil the customer's needs or wishes to the system-to-be, i.e. the customer's 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 for 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.
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 in all project types.
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 is typically expressed in a informal way and represents the customer's expectations to the system-to-be. It is these requirements that must be transformed into requirements for the system-to-be enabling it to fulfil the customer's 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 characterised 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 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 difficult to write the verification, it may be due to an inadequately specified requirement.
A thorough explanation of the requirements capture process can be found through this link
Example
Packages with requirements
One package with an incomplete requirements diagram
