se 555 software requirements & specification1 begin the process

SE 555 Software Requirements & Specification

1

Begin the Process


2

Good Practices

See Wiegers Table 3-1

See Wiegers Table 3-2

Iterative, Incremental Process


3

Wiegers Figure 3-1


4

Wiegers Figure 3-2


5

Requirements Elicitation


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]


7

Requirements Artifacts in

RUP Context

[RUP]


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]


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]


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)


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.


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]


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:


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]


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



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



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]


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



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



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



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?



22

Business Modeling Discipline in the Unified

Process

[RUP]


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]


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



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?



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



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



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



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



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


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


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


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


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


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 & specification1 begin the process

Documents

system rup slide

system market

system benefit

knowledge management

stakeholders use system

use slide

system roi scope

space system development