MobileD/Release Project Process/Explore/
Goal Definition/Initial Requirements Collection Outi Salo & Hanna Hulkko
Version_01_20041013
Initial Requirements Collection
Pattern type:
Phase pattern Stage pattern Task pattern Practice pattern Pattern classification:
Essential Recommended Supporting Optional
The purpose of this task is to produce an initial overall definition of the product’s scope, purpose and functionality. This is needed to enable the further planning and establishment of the project (size, technical issues, architecture, etc.). Also, the documented requirements will be the starting point for the project team to build an overall view on the product at hand. The customer and the steering group should agree and document the central functionality of the product as seen from the customer point of view. Additionally, also other requirements, such as organization’s own business requirements, and constraints to the product development should be identified, agreed upon and documented.
The goals of the Initial Requirements Collection are:
1. To identify and agree the scope, core functionality and relevant non-functional requirements for the software product to be developed.
2. To document the requirements in agreed format.
Entry criteria:
1. The product proposal exists, 2. Contract has been agreed,
3. Exploration group consisting of person(s) responsible for the initiation of the project has been defined, and
4. Stakeholder groups (at least project management and customer) have been defined and allocated for the project.
Inputs:
1. Contract,
2. The product proposal, and
3. Relevant standards (if there are ones).
Name Type
Motivation
Goal
Entry
&
Inputs
Exit
&
Outputs
MobileD/Release Project Process/Explore/
Goal Definition/Initial Requirements Collection Outi Salo & Hanna Hulkko
Version_01_20041013
Exit criteria:
1. Initial requirements for the product have been identified, discussed, agreed upon and documented.
Outputs:
1. Initial requirements document.
The following figure illustrates the sequence of the steps needed to conduct the Initial Requirements Collection.
1. Gather
requirements 2. Discuss requirements
3. Agree upon initial requirements
4. Document initial requirements
The individual steps of an Initial Requirements Collection are:
1. Gather requirements is a step, where raw requirements for the product are collected from different stakeholder groups. While the customer often is the primary source of requirements, other stakeholder groups can also have requirements. For example, if the product will be a part of a product line or family, organization’s business personnel can have requirements for a uniform UI appearance (i.e. it must conform to the rest of the products). Also, different standards or regulations can be a source of requirements (e.g. user must be able to make an emergency phone call with his mobile phone regardless of the state of the application). Additionally, constraints for the product development are identified here. In the development of mobile applications, these constraints can result e.g. from the properties of the target device, and be related to the memory or power consumption of the application.
2. Discuss requirements is a step, where the stakeholder groups go through the gathered requirements together in order to make sure that they are understood the same way, and that there are no conflicts between the requirements. Initial prioritization of the requirements can also be done here.
3. Agree upon initial requirements is a step, where the stakeholder groups decide which of the identified requirements are relevant to the product. In this step, the scope of the product development is set.
4. Document initial requirements is a step, where the mutually agreed requirements for the product are documented in suitable, agreed format.
These documented requirements form the initial Product Backlog.
N/A Process
Steps
Templates
&
Tools
MobileD/Release Project Process/Explore/
Goal Definition/Initial Requirements Collection Outi Salo & Hanna Hulkko
Version_01_20041013
The following roles can be identified in executing the Initial Requirements Collection:
1. The customer group will provide the description of initial functionality of the product
2. The steering group will participate in defining the initial functionality with the customer and accept the documented initial requirements 3. The support group consisting of experts of different areas, such as
business and law personnel, technology experts etc. can be a source of non-functional requirements for the product.
The answers to the frequently asked questions will provide the Initial Requirements Collection with additional in-depth information gained when applying it in practice.
Q How formal should the activities of Initial Requirements Collection be? For example, should some specific methods be used for modelling or validating the requirements?
A Since the purpose of the Initial Requirements Collection is mainly to elicit the initial requirements for the product from the customer and other stakeholder and document them, it can be performed in an informal way, for example, as a workshop or brainstorming session. The requirements obtained in this task will be analyzed in detail first in Product Requirements Analysis task of Initialize phase, and then in the beginning of each iteration in Requirements Analysis task of Productionize phase.
Other patterns which are part of, composed of or associated closely to Initial Requirements Collection are identified here:
• Goal Definition: Initial Requirements Collection is a part of Goal Definition stage.
• Initial Product Planning: the initial requirements defined during Initial Requirements Collection are used as the basis for Initial Product Planning.
If the development project is involved with porting an existing mobile application to another OS or device, Initial Requirements Definition can be done by simply accepting the requirements defined already for the existing application, and accompanying it with end device specific requirements, such as UI style, program size limitations (due to memory size) or display properties.
Roles
FAQ
Related patterns
Variations
Risks
MobileD/Release Project Process/Explore/
Goal Definition/Initial Requirements Collection Outi Salo & Hanna Hulkko
Version_01_20041013
Possible risks which can result from Initial Requirements Collection as well as the solutions including pre-emptive actions for avoiding the risks and actions to take to minimise the risks’ effects are discussed here:
• The requirements are not defined at a sufficiently detailed level.
• Some of the requirements are conflicting.
• The requirements are not understood the same way by all stakeholders.
The aim of Initial Requirements Collection is not to produce a formal and validated requirements specification, but to merely gather all relevant requirements to be used as an input for the incipient development project.
The actual analysis of the requirements will be carried out in later phases of Mobile-D (first in Product Requirements Analysis task of Initialize phase, and then in the beginning of each iteration in Requirements Analysis task of Productionize phase), and thus, the above mentioned problems will be dealt with later, if necessary.
N/A References
&
Further Reading
