1. CS 5150 Software Engineering Lecture 7 Requirements 1

2. CS 5150 2 Administrivia Quiz this evening Rarely one “right” answer Closed book Feasibility study/plan due in a little over a week

3. CS 5150 3 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 & specifications 8.8% Lack of planning 8.1% System no longer needed 7.5% The commonest mistake is to build the wrong system

4. CS 5150 4 Requirements in the Waterfall Process

5. CS 5150 5 Requirements in Iterative Refinement

6. CS 5150 6 Requirements in Incremental Development

7. CS 5150 7 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

8. CS 5150 8 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

9. CS 5150 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 Conflicts Some requirements may conflict with each other Information gathering vs. privacy System performance vs. development cost

20. CS 5150 20 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 21 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