1. Requirements Engineering Determining and Defining the Requirements for the Project

2. What are we trying to do? Define the business need Describe the way the system will be used (e.g., by user scenarios) Delineate (i.e., list) software functions and features Identify project constraints (e.g., software, platform, scope, data, systems)

3. Steps of the Process Inception: defining the business need, primary user(s), functions and features, and constraints (accomplished pre-CS4810) Elicitation: Further requirements gathering activity with greater stakeholder involvement (happening now with customer meeting(s)) Elaboration: “fleshing out” requirements by placing in context with user scenarios (aka, use cases)– a thread of system usage Negotiation: balancing functionality, performance, and “polish” against cost and time to deliver Specification: development of the analysis model (prototype, CRC model, use-case diagrams, textual description) which becomes the “contract” system to be built. Validation: confirmation with the developers and customers that the specification represents the negotiated product Management: ensuring that requirements are represented in further development steps (e.g., the design)

4. Things to Be Using (i.e., Helpful Models) Scenario-Based Models: Use Cases (or User Scenarios or User Stories) Use Case Diagrams Activity Diagrams (e.g., showing major activity sequence) Class-Based Models: Class Diagrams (Object Name, Attributes, and Methods) CRC Cards Behavioral Models: State Diagram (State Name, Attributes, Actions) Flow-Oriented Models: Information Flow Process Flow

5. Additional Points of Emphasis Why requirements are hard to collect (pg 122 7/e, 145 6/e) Incomplete mutual understanding of each others area (e.g., problem domain, possibilities, terms) Requirements conflict or change or are ill-defined Requirements validation checklist (pg 124 7/e, 147 6/e) Identifying stakeholders–ask “who else?” (pg 126 7/e, 150 6/e) Suggested format for requirements gathering (pg 128 7/e, 153 6/e) Identify objects (in/out), services, and constraints Developing a user scenario, see section 5.4, pg 137 7/e, 7.4.3, pgs 158 6/e (see also Pragmatic Programmer, pg 206-207) Guidelines for negotiation (pg 143 7/e, 170 6/e)