CS 5150 Software Engineering Lecture 7 Requirements 1

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

CS 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

CS Requirements in the Waterfall Process

CS Requirements in Iterative Refinement

CS Requirements in Incremental Development

CS 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

CS 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

CS 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

CS 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

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

CS 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

CS 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

CS 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

CS Unspoken Requirements Examples: Resistance to change Social friction Organizational strengths and weaknesses Unspoken requirements are one of the biggest risks in requirements gathering

CS 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

CS 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

CS 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

CS Conflicts Some requirements may conflict with each other Information gathering vs. privacy System performance vs. development cost

CS 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

CS 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