se 555 software requirements & specification1 begin the process
Post on 21-Dec-2015
219 views
TRANSCRIPT
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
6
Elicitation and Analysis: A Dialog
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 requirements artifacts that represent the content and structure of user needs
Users are ignorant and misguided;
developers know best
Users know best and should
dictate design
Dialog: a negotiation, a process of circling in on mutual understanding Merging of the extremes
[Constantine and Lockwood, Software for Use]
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
Problem Analysis
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)
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
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
Techniques:
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
RequirementsAnalyst
EventOwner
Video for Recall
Generate Event-Response Scenarios
Use-case scenario
Exceptions, “what-if”
scenarios
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?