Requirement overview
This menu item is only available if your user group is linked to the role Specification developer in IAM.
Introduction to requirement overview
The specification of requirements in the Software Factory is based on two standards:
- IREB - the deviser for the international certification Certified Professional for Requirements Engineering (CPRE). It is the role of the IREB to draw up a universally accepted international qualification scheme, focused on Requirements Engineering for professionals, through the provision of core syllabi and through the establishment of guidelines for the accreditation and the research. The accreditation process and the certification are regulated by the IREB steering committee.
- IEEE 830 - states that the following objectives are achieved through the drawing up of requirements:
- Requirements serve as the basis for which an agreement can be reached between the customer and the software supplier about what the product has to do.
- Drawing up requirements reduces the effort that is involved in the development of the software because any uncertainties are identified at an early stage.
- On the basis of the requirements, an estimation can be made about the magnitude of the development process.
- The requirements offer a benchmark for validation and verification of the end product.
- Through the platform independent nature of requirements, these can be reused in other environments.
- Requirements serve as a basis for modifications to the system.
An analyst should always strive to keep the requirements independent of the implementation. However, when there are explicit demands regarding the implementation, these should be described or included as attachments as they become part of the basis for the agreement between business and IT.
Roles used in requirement analysis
-
The Specification analysis role can be used to manage all specifications in the Software Factory.
-
The Specification review role can be granted to stakeholders, allowing them read-only access to the specifications. Stakeholders can participate in discussions regarding requirements and can change the specification state and acceptance state of requirements. The Specification review role can access the Software Factory via a Web GUI.
Requirement analysis
The first step in requirement analysis and specification is identification of the stakeholders. Key stakeholders can be granted access to the Software Factory in the role of Specification review.
Next step is elicitation. Via interaction with stakeholders, process analysis and exploration existing systems, the requirements will be identified.
Specifying the business process is a great way to help identify requirements. An analyst will try to determine if and how the system should support each activity in the business process. This will be a great way to prevent scope creep, as requirements that do not support the business process are often categorized as gold-plating.
When an existing system will be replaced, the feature tree will be a good way to traverse this system and find out what the requirements for each feature are. Existing data models can be cross-referenced to see if no features are missing. These two approaches are not mutually exclusive.
Every new requirement should introduce work. When the requirement changes, any work for which no development has been done can be updated accordingly. When work has already started or has already been completed, a new work item should be created to update the software accordingly.
After all work for a requirement has been completed, the stakeholders can verify this via an acceptance test. The results of these test can be registered in the discussion and the acceptance status can be updated accordingly. Both errors in the implementation or errors in the initial requirement specification can lead to new work.
Requirements in the Software Factory
In the Software Factory, the term requirements is only used for a subset of requirements that can be found in literature, namely system requirements. The system requirements answer the how-question. How will the system support a certain user activity? How will the system support a certain feature?
Other questions that can be answered corresponding to other types of requirements, such as why?, what? and when? are answered using the business process tree, the feature tree and the iteration tree.
System requirements can be split into two types: functional and non-functional requirements:
- Functional requirements describe actual functionality that the system provides. These should be the vast majority of the system requirements.
- Non-functional requirements are used to describe other aspects such as performance, ease-of-use. Non-functional requirements are difficult to test, try to set realistic and measurable targets in advance.
Target audience
Requirements should be readable by non-technical stakeholders, so refrain from using technical terms such as tables, columns and triggers. The requirements should answer how the system should support the user, not how a developer would implement this.
In some cases, the stakeholders can express strong opinions about how a developer should implement this. While it is discouraged to include implementation details in the requirements, if these are demands made by the business, these solutions become part of the requirements as they are part of the agreement between business and IT. Attachments can be used to upload state flow diagrams, entity relationship diagrams, wireframes or mock-ups that convey the desired solution.
A formal example of a requirement can be: The system must allow customers to change their invoicing address. This form of self-service reduces workload for the service department. The requirement contains the functionality, the role that can use the functionality and the rationale for the requirement.
However, an analyst is free to use a specification method of their own liking. User stories such as As a customer, I want to be able to change my own invoicing address so I don't have to call the service department would convey the desired functionality just as well.
Forbidden words
Clarity and unambiguity are important when drawing up requirements. All stakeholders should interpret the requirements in the same manner. To avoid the use of vague or technical words, a list of forbidden words can be registered. These words will light up in the requirements description.
An example of a forbidden word being used in a requirement
The list of forbidden words can be accessed from the Advanced menu under Master data - Specification.
Requirement status
Requirements have two types of statuses, one for the requirement itself, the Specification status, and one for the acceptance of the implementation by stakeholders, the Acceptance status.
-
The values for specification status and acceptance status can be changed in the Advanced menu under Master data - Specification. An order number can be specified which decides the ordering of the various statuses in the combo box when changing the status.
-
Additionally, a Progress value can be defined for each status. This value will be used when determining the average progress of all requirements linked to a business process, feature or iteration. Requirements having a specification status or acceptance status with no progress value will be excluded from the calculation of the average specification progress or acceptance progress, respectively.
A default specification status and a default acceptance status are required. These can be set using the corresponding tasks.
Copying requirements
A requirement can be copied by using the Copy requirement task. The task can optionally copy the details of the requirement as well. By selecting a business process, iteration and feature the requirement will be assigned to these items. If these fields are empty the requirement will be created as an unassigned item in the respective tree.
If the requirement has any linked worked items, these can also be copied to the new requirement by checking the checkbox Copy linked work items. The attachments and tags for the work items can also optionally be copied.
Copy requirement task pop-up
Estimation
menu Specification > Requirement overview
Use the field Story points to enter a rough estimation for a requirement.
-
T-shirt sizes are used as default sequence for the story points. The sequence can be changed in the Advanced menu > Master data > Specification > Story points.
-
The sum of remaining work for linked work items is shown as Total remaining hours.
The sum of story points will be shown in the linked iteration.
Fields for requirement estimation
Planning poker for story point estimation
To make a good story points estimation for requirements with your team, a Planning poker feature is available in the Software Factory.
menu Specification > Requirement overview > tab Planning poker
- Each team member should press the Vote
task for their individual estimation of the story points. You can
update your vote by using the task again.
Vote for story points
- All poker votes submitted by the team are hidden until one of the team members presses the Show votes 
task. In this way, everyone can formulate and show their vote without being influenced by others. - Since the individual estimations may lead to discussion, a discussion panel is available. A message in the discussion panel can only be deleted and edited by the team member who wrote it.
- To set the story points for the selected requirement, press the Set story points
task. The highest vote is
selected by default, but this can be changed.
Set story points
Planning poker overview with votes and discussion panel
Comments
menu Specification > Requirement overview > tab Comments
The Comments tab page can be used to leave comments regarding requirements. The main screen contains a prefilter which only shows the requirements with unresolved comments.
Linked work
Requirements generally lead to work. When a requirement is not yet implemented, work can be used to describe how the requirement will be implemented. When a requirement is changed, work can be used to describe the required changes in a model.
menu Specification > Requirement overview > tab Work overview > tab Linked work
The Linked work tab shows the work that is directly linked to this requirement. When a work item is linked to a requirement, it will be placed at the same business process, feature and iteration of this requirement by default.
When work is linked to a requirement, changing the business process, feature or iteration of the requirement will also update the work.
A work item can be explicitly assigned to a different business process, feature or iteration than the requirement.
This exception will remain intact even when the requirement is moved to a different business process, feature or iteration.
When a work item has a different assignment, the value will be highlighted and get a different icon in the corresponding tree: 
.
Tasks are available to restore the business process, feature or iteration of the work item to match the requirement.
Moving the requirement to a different business process, feature or iteration will also update the linked work.
The work will receive an icon indicating the link in each tree: 
.
Linked worked can also be viewed in an object's history. See Viewing an object's history.
An example of a work item assigned to a different iteration than the requirement. The task can be used to quickly re-align the iteration with the requirement.
Log
menu Specification > Requirement overview > tab Log
All changes done to the requirement and the requirement attachments will be logged.