IBS Journal October 2015
Figure 3: CRISP framework dimensions
Dimension 1 Coverage 2 Clarity
Access to best practices: authors of requirement specifications have access to best practices and innovations so that they can embed them into the requirements and truly help in developing a future-ready solution.
Tools: requirement assurance team use tools that help in documenting, indexing and cross-referencing the requirements.
Requirement engineering methodology
To meet the requirements of the CRISP framework, the requirement specification team should follow a well-disciplined methodology for eliciting and document- ing the requirements. The requirement engineering team should use a number of accelerators to facilitate the solution development process. A typical cycle for requirement engi-
neering consists of the phases identified in figure 4.
Conclusion
IT teams should approach the requirement engineering phase with the principle of ‘well begun is half done’. A well-defined set of requirements serve as the basis for a robust IT solution design, which in turn leads to a solution that truly aligns to the users’ needs.
52
Delivera- bles
3 Representation 4 Referenceability Independence
5 6 Indexing & Cross-Referencing
7 Stability 8 Specificity
9 Prioritisation 10 Pragmatism
Measurement of success
Percentage of in-scope business process activities covered in the requirement specification documents.
Number of queries raised by the IT team before both IT and business heads signed it off.
Percentage of users from the user community being represent- ed in the core team that defined the requirements.
Mapping of the number of requirements to the number of functionalities required for delivery.
Number of requirements that are independent of the technol- ogy solution used to fulfil them.
Unique identifiers attributed to each functional requirements which helps in cross-referencing against technology features.
Frequency of changes in requirements during the solution development stage.
Level of specific requirements, avoiding general examples, ambiguous statements or unstated expectations.
Level of prioritisation of the requirements, which help the IT team to deliver requirements in the right sequence.
Extent of practical thought applied to the requirement within the scope and budget limits, instead of ‘asking for the moon’.
Figure 4: Phases of typical requirement engineering cycle Type
Scoping and baselining
Activities • Determine scope of the solution
• Identify end-user community and key stakeholders for the solution
• Assess existing technol- ogy solutions to identify gaps and expectations of users
• Stakeholder map/RACI (responsibility assign- ment) matrix
• Scope/Project charter • System gap analysis
Preparation of require- ment specifications
• Engage with user representatives through interviews, questionnaires and workshops
• Prepare draft of requirement specifications
• Invite queries from the solution developer and update the documents to address them
• Completed questionnaires
• Workshop design docu- ments
• Draft BRS documents
• Vendor queries and responses
• Process maps
Validation and sign-off
• Get requirement specification documents reviewed by business users
• Prepare indexing and cross-referencing of these documents
• Work with vendors to review FSDs aligned to BRDs
• Comments on FSDs from vendors
• Review of release docu- ments from vendors
• Signed-off BRDs
© IBS Intelligence 2015
www.ibsintelligence.com
analysis: requirement engineering
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60
