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 ex - it must 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

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 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.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: 1.Who is behind the request for work? 2.Who will use the solution? 3.What will be the economic benefit of success? 4.Is there another source for the solution?

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  The list of involved stakeholders must be broad!!!! Use real users.  Meetings include the SwEngs and the stakeholders  Use agendas that cover the important points yet encourage flow of ideas  Use wall-stickers, flip-charts, …  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

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

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: 1. Prioritize spoken and unspoken customer wows, wants, and needs; 2. Translate these needs into actions and designs such as technical characteristics and specifications; and 3. Build and deliver a quality product or service by focusing various business functions toward achieving a common goal and customer satisfaction.  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 an “analysis model”  Model Defines information functions  What such a model looks like is the next lecture

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

Specification and Validation  Specification yields the SRS Format of SRS is the next lecture  Validation reviews the SRS