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. Requirement Elicitation 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. Requirement Elicitation 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.