cs 5150 software engineering lecture 7 requirements 1
TRANSCRIPT
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
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