Kiến trúc máy tính và hợp ngữ - Chapter 8: Risks in requirement engineerring

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 cutting- edge 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 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 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. Requirements for highly innovative products: Emphasize marked research, build prototypes, Use customer focus groups to obtain early and frequent feedback about your innovative product visions. 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. 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 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. 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.