text 4

Chapter16

For all types of project and in their different sizes, prioritizing its requirements is a very critical phase in the requirements development process. Prioritizing is also called requirements triage, which helps reveal competing goals, resolve conflicts, plan for staged or incremental deliveries, control scope creep, and make the necessary trade-offs decisions. It is also a way to deal with competing demands for limited resources.

In requirements prioritization, various stakeholders need to participate in the process, from customers, project managers, and developers. A successful prioritization techniques requires an understanding of six issues, which are the needs of the customers, the relative importance of requirements to the customers, the timing at which capabilities need to be delivered, requirements that serve as predecessors for other requirements, which requirements must be implemented as a group, and the cost to satisfy each requirements.

On a small project, the stakeholders should be able to agree on requirements priorities informally. In contrast to larger projects stakeholders demand a more structured approach that removes some of the emotions, politics, and guesswork from the process. There are five techniques for requirements prioritization. The first one is in or out approach, which is the simplest of all prioritization methods is to have a group of stakeholders work down a list of requirements and make a binary decision: is it in, or is it out? The second technique is pairwise comparison and rank ordering. People try to assign to assign a unique priority sequence number to each requirement. Rank ordering a list of requirements involves making pairwise comparison between all of them so you can judge which number of each pair has higher priority. The third technique is three-level scale, which is a common approach that groups the requirements into three levels, high, medium, and low. One way to assess priority is to consider the two dimensions of importance and urgency. The fourth techniques is the MoSCoW, it changes the three-level scale of high, medium, and low to a four-level scale must, should, could, and won’t. The last approach is the $100 technique, where the prioritization team has 100 imaginary dollars to work with. Team members allocate these dollars to “buy” items that they would like to have implemented from the complete set of requirements. They weight the higher priority requirements more heavily by allocating more dollars to them.

A definitive, rigorous way to relate customer value to proposed product features is with a technique called Quality Function Deployment or QFD. This technique was ranked in the top tier of effectiveness in a comparative evaluation of 17 requirements prioritization methods. This scheme borrows from the QFD concept of basing customer value on both the benefit provided to the customer if a specific product feature is present and the penalty paid if that feature is absent. A feature’s attractiveness is directly proportional to the value it provides and inversely proportional to its cost and the technical risk associated with implementing it.

The following steps are to use the prioritization model:

1. List in the spreadsheet all the features, or use cases you want to prioritize.

2. Have the customer estimate the relative benefit each feature would provide on a scale from 1 to 9, where 9 has the highest value.

3. Have the customer estimate the relative penalty each feature would suffer on a scale from 1 to 9, where 9 indicates serious downside.

4. The spreadsheet will calculate the total value for each feature as the sum of its benefit and penalty scores. Then it sums the values for all features and calculate the percentage of the total value that comes from each feature.

5. Have developers estimate the relative cost of implementing each feature on a scale from 1 to 9, where 9 is the most time consuming and expensive. Then let the spreadsheet calculate the percentage.

6. Have the developers rate the relative technical risk associated with each feature on a scale from 1 to 9, where 9 indicated serious feasibility concerns. Then have the spreadsheet calculate its percentage.

7. After entering all estimates, calculate the priority using this formula:

8. Finally, sort the list of features in a descending order by calculated priority. The features at the top of the list have the most favorable balance of value, cost, and risk, and thus have the highest priority.

Chapter17

During the process of requirements development, and after elicitation, analysis, and specification, requirements should be validated. Requirements validation is the forth component of the requirements development process. It assesses whether a product satisfies customer needs (doing the right thing). However, verification determines whether the product of development activity meets its requirements; that is doing the thing right.

Reviewing requirements is a powerful technique for identifying ambiguous or unverifiable requirements. There are two types of requirements reviewing informal and formal. Informal reviews are useful for educating other people about the product and collecting unstructured feedback. It has three approaches peer deskcheck, passaround, and walkthrough. In contrast, formal reviews follow a well-defined process. It produces a report that identifies the material examined, the reviewers, and the review team’s judgment as t whether the requirements are acceptable. The best-known type of formal review is called an inspection.

Inspection is a well-defined multistage process. It involves a small team of participants who carefully examine a work product for defects and improvement opportunities. The following table shows the Fagan inspection technique, and its component.

Component	Description
Participants	There are four categories of participants that should attend the inspection who are the author of the work product and peers of the author, people who are the sources of information that fed into the item being inspected, people who will do work based on the item being inspected, and people who are responsible for interfacing systems that will be affected by the item being inspected.
Inspection roles	Author who creates or maintains the work product being inspected.
	Moderator plans the inspection with the author, coordinates the activities, and facilitates the inspection meeting.
	Reader where one of the inspectors is assigned to be the reader.
	Recorder uses standard forms to document the issues raised and the defects found during the meeting.
Entry criteria	· The document conforms to the standard template and doesn’t have grammatical or formatting errors. · Line numbers or other identifiers are printed on the document to facilitate referring to specific locations. · All open issues are marked as TBD or accessible in an issue-tracking tool. · The moderator didn’t find more than three major defects in a ten-minute examination of a representative sample of the document.
Inspection stages	Planning, preparation, inspection meeting, rework, and follow-up.
Exit criteria	· All issues raised during the inspection have been addressed. · Any changes made in the requirements and related work products were made correctly. · All open issues have been resolved, or each open issue’s resolution process, target date, and owner have been documented.

The following are tips that apply on informal and formal reviews on a project. Plan the examination, start early, allocates sufficient time, provide context, set review scope, limit re-reviews, and prioritize review areas. However, there are some challenges that faces the requirements review process such as large requirements documents, large inspection teams, geographically separated reviewers, and unprepared reviewers.

Chapter 18

One of the eternal goals of increasing software productivity is reuse. Reuse means taking advantage of work that has been done previously, whether on the same project or on an earlier project. The benefits of effective requirements reuse include faster delivery, lower development costs, consistency both within and across applications, higher team productivity, fewer defects, and reduced rework.

There are three dimensions of requirements reuse. The extent of assets being reused, the extent to which an item must be modified for use in its new setting, and the mechanism being used to perform the reuse.

The first dimension has to do with the quantity of material that you are reusing. You might reuse just a single functional requirement, or you might reuse such a statement along with any associated attributes. The second dimension is to consider how much modification will be needed to make existing requirements reusable on the new project. Often, you will start with an existing requirements but modify it to exactly suit the new purpose. The third dimension is the reuse mechanism where the most form of reuse is simply copy-and-paste a piece of requirements information.

Some types of reusable requirements information within a product are user requirements, specific functional requirements within use cases, performance requirements, usability requirements, and business rules. The types of information can be used across a product line are business objectives, business rules, business process models, context diagram, user requirements, user class description, core product features, ecosystem maps, stakeholder profiles, user personas, usability requirements, security requirements, compliance requirements, certification requirements, data models and definitions, acceptance test and glossary.

A requirement pattern offers a systematic approach to specifying a particular type of requirements. A pattern defines a template with categories of information for each of the common types of requirements a project might encounter. It contains six sections, which are guidance, content, template, examples, extra requirements, and considerations fro, development and testing.

Although there are many benefits for requirement reuse, there are some barriers. Missing or poor requirements, NIH (not invented here) and NAH (not applicable here), writing style, inconsistent organization, project type, and ownership. Also, there are success factors such as having a repository, quality, interactions, terminology, and organizational culture.

Chapter 19

One of the earliest project planning activities is to estimate how much of the project’s schedule and effort should be devoted to requirements activities. Small project usually require 15 to 18 percent of their total effort on requirements work, however the exact percentage depends on the size and complexity of the project. One company has developed an approach fro estimating a project’s requirements development effort. This approach involves three complementary estimates: parental of total work; a developer to BA ratio; and an activity breakdown that uses basic resources costs to generate a bottom-up estimate.

The first estimate is based on a percentage of the estimated total project work allocated to requirements activities. It is usually 15 percent of the total project effort. The second estimate assumes a typical ratio of development to business analysts. The default value is 6:1, meaning the one BA can produce enough requirements to keep six developers busy. The third estimate considers the various activities a BA performs, based on the number of artifacts that might be created on a specific project.

After finishing from the requirements development process, and result in a baseline requirements, the project plan, design, code, and testing activities are all derived from that baseline.

Having project plan from requirements is because requirements are the foundation of the project’s intended work; you should base estimates, project plan, and schedules on those requirements. Making realistic estimates of the effort and time needed to complete a project depends on many factors, but it begins with estimating the size of the product being built. You can base size estimates on functional requirements, user stories, analysis models, prototypes, or user interface. However, the best estimation processes acknowledge the early uncertainty and ongoing volatility of scope.

There are two types of scheduling: the first type, “right-to-left scheduling” that is a delivery date is cast on stone and then the product’s requirements are defined. The second type is a “design-to-schedule” strategy. However, an effective project scheduling requires an estimated product size, known productivity of the team, a list of tasks needed to completely implement and verify, reasonably stable requirements, and experience.

Moving to design and code from the requirements is the step following the project planning and scheduling. Therefore, the consideration of what the system is intended to do should not be slanted by design consideration. A product’s functionality, quality attributes, and constraints drive its architecture design. Analyzing a proposed architecture helps the analyst verify the requirements and tune their precision, as does prototyping. Allocation of system capabilities to subsystems and components must be done from the top down. Software design receives short shrift on some projects, yet the time spent on design is an excellent investment. A variety of software designs will satisfy most products’ requirements. As with requirements, excellent designs result from iterations. UI design is so closely related to requirements that you shouldn’t just push it downstream to be done without end-user engagement.

When moving from requirements to testing requirements analysis and testing fit together beautifully. Good requirements engineering produces better tests; good test analysis produces better requirements. The requirements provide the foundation for system testing. The product should be tested against what it was intended to do as recorded in the requirements documentation, not against its design or code. The testers should determine how they’d verify the implementation of each requirement by including the following methods testing, inspection, demonstration, and analysis. The effort invested in early test thinking isn’t wasted, even if you plan a separate system testing effort before release.