Requirements 101

CS3300Fall 2015

Requirements Discipline

Elicitation Analysis Specification Validation Control Traceability

Definition

A property or behavior that a software system must have to solve a particular problem.

Functional and Non-Functional Requirements

Characteristics:

Correct, Complete, Unambiguous, Testable, Consistent

Most Important Idea

Requirements are what

the system has to doNOT how it will do it.

Key words

Shall, Must – some the system is required to do

Should – a preferred but optional feature May – a nice to have feature

You have to do all the “shalls”. The more of the “shoulds” that you can do, the more happiness you give the customer. “Mays” usually are customer suggestions, but you don't have to follow them.

Quality Function Deployment Ideas

Normal Requirements – objectives stated by customer

Expected Requirements – implicit to the product (ease of use, ease of installation)

Exciting Requirements – exceeding the customer expectations

Some Examples, are they good or bad?

4.1.3 The software shall be easy to use.

3.1.1.2 The quarterly report view shall show the total sales for the quarter in a prominent place.

3.3.2.1 User login shall be accomplished in no more than 1 second.

More Examples

3.2.1.4 The software shall enforce a user id format of 4-8 characters, one of which must be a letter, at least one must be a symbol and at least one must be a digit.

3.2.1.5 Each user id must be unique.

3.5.4.1.1.1 The report shall display information such as name, ssn, and amount due.

Your turn

Write one good requirement for t-square.

There is a piazza thread for you to enter.

Non-Functional Requirements

Performance (Are there constraints on speed, memory usage, etc)

Reliability (Mean Time Between Failure) Availability (What is required up time?) Portability (What platforms does this have to

run on?) Interoperability (What other systems do you

need to play nice with?) Accuracy (What precision does data need?)

More NFR's

Maintainability (Special constraints on operating the system)

Extensibility (Run time modification of the system – like Eclipse plug-in system)

Expandability (Add new features, hooks and design)

Safety (Fault tolerance and hazard analysis) Security (threat models and analysis) (

http://www.sans.org/top25-software-errors/ )

Big Problem

Getting good requirements is HARD Thus was invented numerous techniques

beyond the basic interview / survey / observation / document review

Conflict resolution is also a major issue Identifying hidden affordances and work

processes

Techniques

Joint Applications Development (IBM 77-84) Contextual Design (Holtzblatt and Beyer 98) Win Win (Boehm 98)

JAD Capers Jones states, "A study of over 60 projects ... showed

that those projects that did not use JAD missed up to 35% of required functionality resulting in the need for up to 50% more code." The Capers Jones study determined that projects that used JAD missed only 5 percent to 10 percent of required functionality with minimal impact on the code.

·David Freedman states, "How do you design a system that users really want? ... You can't. What you can do is help users design the systems they want."

·"The successful use of JAD has pushed its use beyond traditional applications of the process. JAD is being used successfully for strategic systems and data planning, as well as for projects outside the IS community."—General Electric

Contextual Design Assumptions

Challenge of design is to fit system into everyday life – be non-intrusive

Social aspects are as important as technical aspects

Systems impose a model of work on the users

Good design = optimal match between user's desired way of doing work and the model imposed by the system.

Design depends on seeing implications of data

System is more important than individual features

Design Models

Flow Diagram – Communication and Coordination necessary to do the work

Sequence Model – Detailed work steps to achieve an intent

Artifact Model – Physical things created to support work

Cultural Model – Constraints on work due to policy, culture or values

Physical Model – Physical structure of the work environment and it affects the work.

Consolidated Models

All the above plus

Affinity Diagram – Pull key concepts out of other models, group together by similarity

Theories of Management

Theory X – Employees are basically lazy, require close supervision

Theory Y – Employees want to do the right thing, managers just have to provide environment, can cause conflicts

Theory Z – Increase loyalty by providing stable enviroment, focus on employee well-being, build shared values to reduce conflict

Win Win

Theory W – figure out win conditions of employees and meet them.

What are the win conditions of stakeholders? How can we make everyone win? Boehm Paper in readings Resolve conflicts

Specification

The SDS - oriented to the users

The SRS – oriented to the developers

See format in resources

ValidationRequirements Review

Prototype

Use Case Walkthrough

Acceptance Tests

Model Validation

ControlGold-Plating

Feature Creep

Bad –

Just code the changes, add scenarios as you discover them

Good –

Add them to product backlog

http://www.stevemcconnell.com/rdenum.htm

28-32

Traceability

Every requirement is identified (usually with a unique paragraph number like 3.1.4.3)

Every requirement has a traceable source (where it came from).