Requirements Gathering How do we find out what we are supposed to be building?

Why good Specs are Essential: $ It is VERY expensive to fix problems late in the process. It is very cheap to rewrite or clarify a written spec. What costs $1 to fix at ReqGathering $5 in the design stage $10 in the coding stage $20 in the unit testing phase $200 after delivery

Types of Requirements Functional Non-Functional Explicit Implied ex - it must email the sales manager when an inventory item is "low" Non-Functional ex - it must require less than one hour to run Explicit ex – required features Implied ex – software quality Forgotten ex – exists in current process Unimagined

Questions What makes a particular requirement good or bad? Why is requirements engineering difficult?

Requirements of Requirements Clear Measurable Feasible Necessary Prioritized Concise

Req Gathering Problems Accommodating changing reqs Being complete, without being constraining Conflicting views Ease of omitting obvious info Identifying the experts and getting authority to talk to people Incomplete understanding of the problem on the part of the user/customer Sticking with “what” and not “how” Determining what is critical Avoiding mission creep

Requirements WILL Change

Requirements Engineering Tasks Inception Elicitation Elaboration Negotiation Specification Validation Management Software Engineering: A Practitioner’s Approach by Roger Pressman

Inception Project starts due to a business decision Software Engineer Asks: What is the basic problem Who wants a solution Nature of solution

Inception Project starts due to a business decision Software Engineer Asks: What is the basic problem Who wants a solution Nature of solution First Questions: Who is behind the request for work? Who will use the solution? What will be the economic benefit of success? Is there another source for the solution?

Elicitation Methods Interviews Use Cases Formal Requirement Engineering Techniques

Elicitation via Interviews

Elicitation via Interviews Difficulties: Ill-defined project scope Unnecessary details that confuse Not sure what they need Poor understanding of capabilities Omitting the “obvious” Requirements that conflict with other people’s requirements Requirements Change!!!

Elicitation via Interviews Recommended Practices: The list of involved stakeholders must be broad!!! Be sure to use real end-users. Use agendas that cover the important points yet encourage flow of ideas Ahead of time, the participants should build a partial list of the functions, performance criteria, environment factors, … Start with scope and context, move to functions Use visuals such as wall-stickers, flip-charts, … Meetings with stakeholders should include the SwEngs

Elicitation via Use Cases Diagrams composed of Actors and Actions Logout Anonymous User Registered User Create Account Manage Account Credit Card System

Joint Application Design Elicitation via JAD Joint Application Design JAD Sessions Participants: Executive Sponsor Project Leader Facilitator – trained and experienced Recorder Participants Observers – developers who sit on sideline and don’t talk Outputs of sessions: Data flow diagrams Data requirements List of assumptions etc

Elicitation via QFD Since 1966, Quality Function Deployment (QFD) has been used world wide in nearly every industry and sector to: Prioritize spoken and unspoken customer wows, wants, and needs; Translate these needs into actions and designs such as technical characteristics and specifications; and Build and deliver a quality product or service by focusing various business functions toward achieving a common goal and customer satisfaction. www.qfdi.org QFD uses interviews, surveys, and data (problem reports) to build a table of requirements called the Customer Voice Table. Functional Deployment – value of each function Information Deployment – identify the input and output Task Deployment – examine system behavior Value Analysis – prioritize the requirements

Elaboration Goal is to create a model that defines: information functions What such a model looks like is the 2nd half of tonight http://www.camsp.com/cornerstone/assets/images/resources/when_use_maps_sm.png

Negotiation Goal is to resolve requirements that are Conflicting Costly Unrealistic Identify the subsystem’s stakeholders Determine their win conditions Negotiate their win conditions into win-win conditions for everyone

Specification and Validation Specification yields the SRS Format of SRS is the 2nd half of tonight Validation reviews the SRS

Review Requirements Engineering Tasks Inception Elicitation Elaboration Negotiation Specification Validation Management