Lecture Requirement engineering Chapter 8 Risks in requirements engineering

Lecture Requirement engineering Chapter 8 Risks in requirements engineering. This chapter presents the following content Element risks management, risk assessment, risk avoidance, risk control, product vision and scope,...

 Risk management provides a standard approach to Identify and document risk factors Evaluate their potential severity Propose strategies for mitigating them  Risk assessment: is the process of examining a project to identify areas of potential risk Risk identification: makes lists of common risk factors for software projects Risk analysis: Examine the potential consequences of specific risks to your project Risk prioritization: focus on the most severe risks by assessing the potential risk exposure from each  Risk avoidance : You can avoid risks by not undertaking certain projects, by relying on proven rather than cuttingedge technologies, or by excluding features that will be especially difficult to implement correctly Software development is intrinsically risky, though, so avoiding risk also means losing an opportunity  Risk control: manage the top-priority risks Risk management planning: produce a plan for dealing with each risk including mitigation approaches, contingency plans, owners, and timelines Risk resolution involves executing the plans for mitigating each risk Risk monitoring: track your progress toward resolving each risk item through  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  Product Vision and scope: Team members don’t have a clear, shared understanding of what the product is supposed to be or  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 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  you can judge whether it is sufficient and improve your planning for future projects  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  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  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  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)  Document the requirements that you discover through reverse engineering, and have customers review those requirements to ensure that they are correct and still relevant  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,  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  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  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  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  Unverified requirements 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  Inspection proficiency: Serious defects might be missed in case inspectors 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  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  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 ... support the defined procedure is an important starting point  Unimplemented requirements The requirements traceability matrix helps to avoid overlooking any requirements during design, construction... learning, experimentation and prototyping  Requirement Understanding: Different understandings of the requirements by developers and users may lead to expectation gaps Formal inspections of requirements. .. missed in case inspectors not know to properly inspect requirements documents, and to contribute to effective inspections Train all team members who will participate in inspections of requirement