CS 5150Software

EngineeringLecture 7

Requirements 1

2CS 5150

Administrivia

• Quiz this evening

• Rarely one “right” answer

• Closed book

• Feasibility study/plan due in a little over a week

3CS 5150

Why are Requirements Important?

• Causes of failed software projects (Standish Group study, 1994)

• Incomplete requirements 13.1%

• Lack of user involvement 12.4%

• Lack of resources 10.6%

• Unrealistic expectations 9.9%

• Lack of executive support 9.3%

• Changing requirements & specifications8.8%

• Lack of planning 8.1%

• System no longer needed 7.5%

• The commonest mistake is to build the wrong system

4CS 5150

Requirements in the Waterfall Process

5CS 5150

Requirements in Iterative Refinement

6CS 5150

Requirements in Incremental Development

7CS 5150

Requirements Goals

• Understand client/user requirements in detail

• Requirements “text” must be understandable to clients/users

• Actual text

• Diagrams

• Prototypes/mock-ups

• Requirements much be understandable to designers, developers, testers, maintainers

• Part of requirements gathering is ensuring that all the relevant players understand them

8CS 5150

Functional Requirements

• Functional requirements describe the high-level functions the system should perform, little to no reference to underlying technology issues

• Major workflows

• Data collected/managed

• User interface idioms

9CS 5150

Implementable and Verifiable

• Developers should be able to imagine a realistic implementation of any requirement

• Bad example: The system must process stock trades between London and Chicago with nanosecond latency

• Bad example: The system must identify errors in user input with 100% accuracy

• There must be a way to unambiguously verify whether a requirement has been met

• Bad example: The system should be easy to use

• Better example: Typical internet users should be able to use the system after completing a short tutorial

10

CS 5150

Stages in Requirements Gathering

• Analysis: Translate vague ideas about what the system should do into a detailed and concrete set of functions, services, goals and constraints

• Modeling: Organize the requirements into an easier to digest and understand framework (next two lectures)

• Define, record and communicate: Make sure requirements are recorded in a convenient format and that all the players (developers, client, etc) understand them

11

CS 5150

Requirements Analysis

• Specifies external system behavior

• Comprehensible by managers, customers, users, etc

• Covers:

• Functions and services the system will provide

• Constraints under which it will operate

• Often described in its own document:

• “Our understanding of the requirements for system X are ...”

12

CS 5150

Interviews with Clients and Users

• Interviews with clients and users are at the heart of requirements analysis

• Allow plenty of time; perhaps multiple meetings

• Prepare questions before meeting

• Keep notes; index cards often work well

• If you don’t understand, don’t let it slide

• Small meetings are often most effective

• Repeat what you hear

13

CS 5150

Understand the Requirements

• Domain understanding

• May need to spend extra time learning the client/user’s lingo

• Try to understand the fundamental requirements of all stakeholders

• May need to interview several different people

• Stakeholders often don’t have a clear vision of what the proposed system could do for them

14

CS 5150

New and Old Systems

• It is important to distinguish

• Features of existing systems

• Proposed new features

• Clients often confuse their current way of doing things with requirements for the new system

• New systems

• Replacement systems

• Legacy systems

15

CS 5150

Unspoken Requirements

• Examples:

• Resistance to change

• Social friction

• Organizational strengths and weaknesses

• Unspoken requirements are one of the biggest risks in requirements gathering

16

CS 5150

Stakeholders

• A stakeholder is anyone affected by the system

• Client

• Senior management

• Deployment staff

• Users

• People whose information is collected

• Example:

• Web shopping site

• Customers, accounting dept, warehouse managers

17

CS 5150

Viewpoint Analysis

• Critique the requirements from the point of view of a particular stakeholder

• Get a real person, if that is feasible

• Otherwise, do your best to role-play

• Write a short separate document for each viewpoint

18

CS 5150

Special Studies

• If the team does not have the necessary information or experience to be confident about the requirement ...

• Market research

• Focus groups, surveys, competitive analysis, etc

• Technical research

• Prototypes, experiments, literature survey, etc

19

CS 5150

Conflicts

• Some requirements may conflict with each other

• Information gathering vs. privacy

• System performance vs. development cost

20

CS 5150

Negotiation

• Sometimes client are unrealistic about what they want

• Extended discussion of relevant requirements. Are there cheaper alternatives?

• Explain the specific reasoning behind developer’s concerns

• Be open to creative solutions

• Leaving these issues unresolved is a big risk

21

CS 5150

Requirements Role-Playing Exercise

• Get in groups of 2

• Different projects

• Take turns gathering requirements from each other

• One person plays the role of being their own team’s client

• Make up details if you have to