Requirement-Related Risks

1. Requirement-Related Risks Extracted from the book: Software Requirements By Karl E.Wiegers

2. Introduction • Risks factors are organized by the requirements engineering sub-disciplines: • Elicitation • Analysis • Specification • Verification • Management • Techniques are suggested that can reduce: • Either the probability of the risk materializing into a problems • Or the Impact on the projects if it does.

3. RequirementElicitation • Product Vision and scope: • Scope creep issue: • occurs if team members don’t have a clear shared understanding of what the product is supposed to be or do. • Early in the project write a vision and scope document that contains your business requirements and use it to guide decisions about new or modified requirements. • Time spent on requirements development • Tight projects schedules often pressure managers into glossing t over the requirements. • A rough guideline is to spend about 15 per cent of your project effort on requirements development activities. • Keep records of how much efforts you actually spend on requirements development: therefore you can judge whether it is sufficient and improve your planning for future projects.

4. RequirementElicitation • Completeness and correctness of requirements specification • Apply the use case technique to elicit requirements by focusing on user tasks. This ensure that you will capture real customer needs. • Devise specific usage scenarios. • Write test cases from requirements • Create prototypes to make the requirements more tangible for users and to elicit specific feedback from them. • Requirements for highly innovative products: • Easy to misgauge market response to products that are the first of their kind. • Emphasize marked research, build prototypes, • Use customer focus groups to obtain early and frequent feedback about your innovative product visions.

5. Requirement Elicitation • Defining Non functional requirements • Natural emphasis on product functionality and easy neglect of non functional ones. • Query customers about quality characteristics: performance, reliability, usability…. • Document these NF requirements and their acceptance criteria in the SRS document. • Customer agreement on product requirements: • Determine who the primary customers are. • Make sure you have adequate customer representation and involvement • Make sure you are relying on the right people for decision making authority on requirements.

6. Requirement Elicitation • Unstated requirements: • Customers might hold implicit expectations that are not communicated or documented. • Try to identify and record any assumptions the customers might be taking. • Use open ended questions to encourage customers to share more of their thoughts, ideas and concerns than you might otherwise hear.

7. Requirement Elicitation • Existing product used as the requirement baseline: • Developers are sometimes told to use the existing product as their source for requirements (fix specific bugs, add new features). • Thus new requirements are discovered through reverse engineering: INEFFICIENT and IMCOMPLETE WAY. • Document the requirement you discover through reverse engineering and have customers review those requirements to ensure they are correct and still relevant. • Solutions presented as needs: • User proposed solutions can mask the user’ actual needs. • May lead to automating ineffective business processes or to pressure developers into making poor design decisions. • You must drill down to understand the intent behind the solution the customer has presented

8. Requirement Analysis • Requirement prioritization • Ensure that every requirement, feature or use case is prioritized and allocated to a specific product release or implementation stage. • Evaluate the priority of every new requirement against the existing body of work remaining to be done so you can make clever trade-off decisions. • Technical difficult features: • Evaluate the feasibility of each requirement to identify those that might take longer to implement than planned. • Use your project status tracking to watch for requirements that are falling behind their implementation schedule. • Take corrective action as early as possible,

9. Requirement Analysis • Unfamiliar technologies, methods, tools, or hardware • Don’t underestimate the learning curve of getting up to speed with new techniques that are needed to satisfy certain requirements • Identify those high risks requirements early • Allow sufficient time for false starts, learning, experimentation and prototyping.

10. Requirement Specification • Requirement Understanding: • Different understandings of the requirements by developers and users may lead to expectation gaps. • Formal inspections of requirements documents by teams including developers, testers, and customers can mitigate the risk. • Trained and experimented requirements analysts will ask the right questions and write better specification. • Models and prototypes that represent the requirements from multiples perspectives will reveal fuzzy and ambiguous requirements.

11. Requirement Specification • Time pressure to proceed despite TBDs • Good idea to mark areas of the SRS document that need further work with ‘to be determined’ (TBD). • But it is risky to proceed with the construction if these TBDs have not been resolved. • Record the name of the individual responsible for resolving each TBD, how it will resolved, and the target date for resolution. • ِAmbiguous terminology • Create a glossary and data dictionary to define all business and technical terms that might be interpreted differently by different readers. • Especially define terms that have both common and technical or domain-specific meanings • ٍSpecific reviews can help participants reach a common understanding of key terms and concepts.

12. Requirement Specification • Design included in requirements: • Design approaches included in the SRS document place unnecessary constraints on the options available to developers and can inhibit the creation of optimal designs. • Review the requirements to make sure they emphasize what needs to be done to solve the business problem, rather than stating how it will be solved.

13. Requirement Verification • Unverified requirements • Inspecting a lengthy SRS, writing test cases very early in the development process may appears fastidious. • However if you verify the quality and correctness of the requirements before construction begins, through inspection, requirements-based test planning and prototyping you can greatly reduce expensive rework later in the project. • Include time and resources for these quality activities in he project plan. • Gain commitments from your customer representatives to participate in requirements inspections. • Perform incremental, informal reviews prior to formal inspections to find problems as early and cheaper as possible.

14. Requirement Verification • Inspection proficiency: • ٍSerious defects might be missed in case inspectors do not know to properly inspect requirements documents, and to contribute to effective inspections. • Train all team members who will participate in inspections of requirement documents. • Invite an experienced inspector from your organization or outside consultant to observe and moderate your early inspections to help make them effective.

15. Requirement Management • Changing requirements • Scope creep can be reduced by using a project vision and scope document as the benchmark for approving changes. • A collaborative requirement elicitation process with extensive user involvement can reduce scope creep by almost half, • Quality control practices that detect requirements errors early can reduce the number of modifications requested later on. • To reduce the impact of changing requirements, defer implementation of those requirements that most likely to change until they are pinned down, and design for modifiability.

16. Requirement Management • Requirement change process: • Risks from the way changes to requirements are managed include not having a defined change process, using an ineffective change mechanism, and permitting changes to be made without following the process. • You will need to develop a culture and discipline of change management at all levels. • A requirements change process that includes impact analysis of proposed changes, a change control board to make decisions, and a tool to support the defined procedure is an important starting point.

17. Requirement Management • Unimplemented requirements • The requirements traceability matrix helps to avoid overlooking any requirements during design, construction or testing. • It also helps ensure that a requirement is not implemented by multiple developers because of inadequate communication within the project. • Expanding project scope • If requirements are poorly defined initially, further definition can expand the scope of the project. • The project resources that were allocated according to the initial requirements might not be adjusted as the true scope of user needs becomes known. • To mitigate this risk, plan on a phased or incremental delivery process. • Implement the core functionality in the early releases, and iteratively elaborate the requirements for the later phases.