Begin the Process

1. Begin the Process SE 555 Software Requirements & Specification

2. Good Practices • See Wiegers Table 3-1 • See Wiegers Table 3-2 Iterative, Incremental Process SE 555 Software Requirements & Specification

3. Wiegers Figure 3-1 SE 555 Software Requirements & Specification

4. Wiegers Figure 3-2 SE 555 Software Requirements & Specification

5. Requirements Elicitation SE 555 Software Requirements & Specification

6. Elicitation and Analysis: A Dialog • Dialog: a negotiation, a process of circling in on mutual understanding • Merging of the extremes • Learning about what users really need from software to support their work (as distinct from what they want or what they merely think they need) requires a dialog between analysts/designers and users. • The joint understanding is embodied in requirementsartifacts that represent the content and structure of user needs Users are ignorant and misguided; developers know best Users know best and should dictate design [Constantine and Lockwood, Software for Use] SE 555 Software Requirements & Specification

7. Requirements Artifacts in RUP Context [RUP] SE 555 Software Requirements & Specification

8. Formulate a Vision • Purpose • Gain agreement on what problems need to be solved • Identify stakeholders of the system • Define the boundaries of the system • Describe primary features of the system [RUP] SE 555 Software Requirements & Specification

9. Find the Problem • Ask, “What is the Problem” • You will often get myriad solutions, but there is a problem in there somewhere • Ask, “What is the problem, really?” • Search for root causes • Consider fishbone diagrams • Discover “the “problem behind the problem” • Continue to ask “Why?” • If there is an obsessive focus on solution, explore the benefits of the proposed solution for insight to the problem solved by those benefits [RUP] SE 555 Software Requirements & Specification

10. Who? (stakeholders) Use system Pay for system Build system Test system Document system Support system Maintain system Market, sell, distribute system Install system Benefit from the system ROI Scope and its charge What system is What system is not Constraints Environmental Budget Scheduling Product Position Statement For (customer) Who (driving/matching characteristics) The (product name and feature description) That (benefits) Unlike (existing solutions) Our product (is an x that provides y) Problem Analysis SE 555 Software Requirements & Specification

11. A Product Position Statement Unlike a generic document management or knowledge management system with keyword-based search and retrieval, the NASA Standards Advisor will leverage explicit knowledge about the content and organization of standards and lessons learned and their role in space system development. Using this knowledge, the Standards Advisor can increase the effectiveness of developers by selecting and delivering an organized set of documents that meet the specific needs of each developer. SE 555 Software Requirements & Specification

12. Example Product Position Statement Unlike a generic courseware management system with keyword-based search and retrieval, the RIT eNotebook will leverage explicit knowledge about the content and organization of course materials and their role in the curriculum. Using this knowledge, the RIT eNotebook can increase the effectiveness of learners by selecting and delivering an organized set of documents that meet the specific needs of each learner. [RUP] SE 555 Software Requirements & Specification

13. Elicitation: Discover Stakeholder Requirements Techniques: • Interviews • Ethnographic studies (observe the user using similar systems) • Questionnaires • Requirements workshops • Brainstorming and idea reduction • Storyboarding • Study similar products & relevant docs • Use cases • Prototyping • Context-free questions Donald Gause and Gerald Weinberg, Exploring Requirements: Quality Before Design SE 555 Software Requirements & Specification

14. Trawling for Requirements • Trawling metaphor: Run a net through the organization to catch every possible requirement • May catch inappropriate requirements • They will be filtered out later • Goal: Don’t miss any requirements • The analyst instigates requirements elicitation • But users, customers, clients, support staff, etc., are the ones who have and know the requirements • They have a responsibility to contribute to the effort • Analyst is a translator: understand the nature of the problem and translate it into a specification for a product/solution • Note that the analyst contributes too: a product vision/invention [Robertson and Robertson] SE 555 Software Requirements & Specification

15. Trawling for Requirements • Trawling metaphor: Run a net through the organization to catch every possible requirement • May catch inappropriate requirements • They will be filtered out later • Goal: Don’t miss any requirements • The analyst instigates requirements elicitation • But users, customers, clients, support staff, etc., are the ones who have and know the requirements • They have a responsibility to contribute to the effort • Analyst is a translator: understand the nature of the problem and translate it into a specification for a product/solution • Note that the analyst contributes too: a product vision/invention [Robertson and Robertson] SE 555 Software Requirements & Specification

16. Analyst Role • Observe and learn the user needs and tasks (the problem) and understand them from the user point of view • What they are doing and why • Interpret the user work/tasks • Filter out technology and current way of doing things to get to the essence of the work, not its incarnation • Invent better ways to do the work • Interpret what the product must do to satisfy the essential requirements • Record the results in the form of a requirements specification and analysis models • Validate that the analyst and user have the same understanding of the problem and the product, and that the user agrees that this is the product wanted [Robertson and Robertson] SE 555 Software Requirements & Specification

17. Trawling Techniques • There are techniques to help with trawling for requirements • Select the techniques that best fit the situation • Consider your users • Users will be very conscious of some requirements • There will also be many “unconscious” requirements • In-grained, second-nature, no longer aware they exist • There will also be “undreamed-of requirements” • Features and functions the user is not aware they could have • Different techniques for different types of requirements [Robertson and Robertson] SE 555 Software Requirements & Specification

18. Apprenticing • Serve as an apprentice to the master craftsman to learn their work • Observe, ask questions, do some of the work under the master’s supervision • Identify concrete artifacts, procedures, exceptions, constraints, techniques • “Nobody can talk better about what they do and why they do it than they can while in the middle of doing it.” • Hugh Beyer and Karen Holtzblatt, Contextual Design: Defining Customer-Centered Systems, Morgan Kaufmann, 1998. • In parallel with the user, validate analyst models and discuss feasibility of possible solutions • Interpret: abstract away from the user’s close connection to the physical incarnation of the work [Robertson and Robertson] SE 555 Software Requirements & Specification

19. Interview the User • Interviewing is a common approach, but may not be most effective • Assumes users will know and be able to discuss their requirements • Questions often lead to specific answers and scope • Questionnaire • Consider it as pre-work to a personal interview • Engage the user in the process so they are not passive • Interactively build models, for example [Robertson and Robertson] SE 555 Software Requirements & Specification

20. Interview Structure • Set the interview in context to set scope and direction of discussion • Use business events as an anchor; work one event at a time • Ask a question, listen to the answer, then feed back your understanding • Draw models and encourage user to change them • Data flow models and work flow charts are effective • Consider UML Activity Diagrams with data flow • Use the user’s terminology and artifacts, both conceptual and real • Artifacts: papers, computers, meters, spreadsheets, machines, instruction lists, software applications, etc. • Avoid letting the user speak in technology/solution • Keep sample artifacts and documents • Thank the user for their time and tell them why it is valuable [Robertson and Robertson] SE 555 Software Requirements & Specification

21. Business Event Workshops • Business events • Businesses respond to events that are (typically) initiated outside the scope of work to be done (by a user or an adjacent system) • A pre-planned response triggered by • Arrival of information • Arrival of request • Passage of time • The response to the event is a unit of work to be studied • A use case • In a business event workshop, the responsible user describes or re-enacts the work that is done in response to the event • Identify data, processes, messages, subtasks, checkpoints, etc. • What contribution is to be made by the software product? [Robertson and Robertson] SE 555 Software Requirements & Specification

22. Business Modeling Discipline in the Unified Process [RUP] SE 555 Software Requirements & Specification

23. Business Event Workshops Use-case scenario Generate Event-Response Scenarios Exceptions, “what-if” scenarios Video for Recall Requirements Analyst Event Owner Business Rules Low-fidelity Interaction Screens [Robertson and Robertson] SE 555 Software Requirements & Specification

24. Deliverables of the Business Event Workshop • Purpose of the business event • Desired outcomes for the business • Scenarios of the work (to be) done to respond to the business event • “What-if” scenarios about things that can go wrong when the event happens • The business rules that apply to that part of the work • The part of the work to be done by the product separated from the part that is done by people and other systems • The likely users of any product built for this event • Prototypes for some of the steps • Minimal detail • Optional [Robertson and Robertson] SE 555 Software Requirements & Specification

25. Purpose of the Business Event • Focus on the outcome the organization hopes to achieve whenever the event happens • Think of outcomes, not outputs • Example: car rental • Outcomes: customer drives away in car of their choice, rate selected is equitable, details are recorded, minimal customer and clerk inconvenience, minimal cost • Outputs: rental document, recorded data • From organization’s view or customer’s view • What are you trying to achieve? • Why is this important? • An outcome is a business objective, not a way of achieving something • Should be able to write in one sentence • If this event happens, what state of affairs do you want to exist when the work is finished responding? [Robertson and Robertson] SE 555 Software Requirements & Specification

26. Requirements Analysis After the Workshop • Analyze each event response and answer: • What does the product have to do to complete this step? • What non-functional requirements are necessary for this step? • Quality requirements • Constraints [Robertson and Robertson] SE 555 Software Requirements & Specification

27. Brainstorming • Brainstorming is good for invention taking advantage of the “group effect” • “Invent” the need and/or the solution • (See earlier slides on brainstorming) • Use brainstorming to discover new requirements and to create new possible solutions • “Out there” ideas without criticizing or debating • (In a requirements context) the best and most usable ideas will, with the client’s consent, become requirements for the product [Robertson and Robertson] SE 555 Software Requirements & Specification

28. Rules for Brainstorming • Diverse disciplines and backgrounds • For this session, suspend judgment, evaluation, and criticism • Don’t stop the creative flow • Produce lots of ideas • Quantity will, in time, produce quality • Come up with ideas that are unconventional, crazy, wild, etc. • This will produce really useful requirements • Piggyback a new idea on an old one – use ideas to stimulate new ideas • Write every idea down, without censoring • “Ideas disappear faster than water evaporates unless written down” [Alex Osborne, the founder of brainstorming] • If you get stuck, seed the session with a word pulled randomly from a dictionary • Word associations, using the word as a springboard [Robertson and Robertson] SE 555 Software Requirements & Specification

29. After the Brainstorming Session • Analysts and clients evaluate the ideas • Some worthless, but they will have served their purpose of inspiring other, more practical, ideas • Keep the best and (if feasible) turn them into requirements • Merge ideas • Merge half-formed ideas into an invention • Form half-formed ideas into true requirements • Investigate ideas with additional trawling techniques [Robertson and Robertson] SE 555 Software Requirements & Specification

30. Context-Free Questions – Process-Oriented • User • Who is the customer? • Who is the user? • Are their needs different? • What are their backgrounds, capabilities, environments? • What is the reason for wanting to solve this problem? • What is the value of a successful solution? • How do you solve the problem now? • Can we copy that solution? • How much time do we have? • What is the trade-off between time and value? • Who should be on the team(s)? Gause and Weinberg SE 555 Software Requirements & Specification

31. Context-Free Questions – Product-Oriented • What problems does this system solve? • What problems could this system create? • What environment will the product be used in? • What are your expectations for usability, reliability, performance, etc.? Gause and Weinberg SE 555 Software Requirements & Specification

32. Context-Free Questions – Meta-questions • Am I asking too many questions? • Do my questions seem relevant? • Are you the right person to answer these questions? • To assure we understand each other, may I write down the answers to these questions and give you a written copy to study and approve? • Is there someone else who can give me useful answers? • Is there some way I can see the environment in which the product will be used? • Are your answers official requirements? • Is there anything else I should be asking you? • Is there anything you want to ask me? • Can I ask more questions later? Gause and Weinberg SE 555 Software Requirements & Specification

33. Group Dynamics:Be sensitive to them & probe them • I noticed you hesitated (had trouble describing, etc.). Is there something else we should know? • When I asked X about that, she said Y. Do you have any idea why she might have said Y? • I notice you don’t seem to agree with that reply. Would you tell us about that? • Are you comfortable with the process right now? • Is there any reason you don’t feel you can answer freely? • What can you tell me about the other people on this project? • How do you feel about the other people working with us on this project? • Is there anybody we need on this project whom we don’t have? • Is there anybody we have on this project whom we don’t need? Gause and Weinberg SE 555 Software Requirements & Specification

34. Plan Your Tasks • Identify the techniques that are most appropriate and will have the greatest impact • What resources to do have? • Is there any sort of research that you need to do? • Distribute the work and manage your time SE 555 Software Requirements & Specification

35. Your Project • Identify the elicitation techniques that are appropriate and have the greatest impact. • What tasks are involved to plan, execute and document the results for each identified technique? • What stakeholders will you interact with for each technique? • How much time do you plan for each technique? SE 555 Software Requirements & Specification