The Trouble with Requirements

1. The Trouble with Requirements From Use Cases – Requirements in Context Second Edition

2. Traditional Activities • Typical development activities include: • business modeling • requirements gathering, • analysis and design, • construction, • testing, • deployment and • maintenance. • Frequently given lip service: • Business modeling • Requirements gathering • Testing • Deployment • Maintenance

3. Landscape of Requirements • Perception changing from only emphasizing big three: • Analysis, design, and construction • Realization of criticality of requirements!! • More projects fail due to poor requirements specification and poor requirements management than for any other reasons. • Requirements are difficult to capture • Maybe from drawing, org charts, pure text • Don’t translate nicely into pure modules that programmers know and love. • Difficult for programmers (dealing with the concrete) to comprehend abstractions of requirements.

4. Landscape of Requirements • We don’t like to spend lots of time here • “Takes too long” • We like to plod on (often operating under false assumptions). • In fairness: • Huge volumes of requirements (lists) (Tab 1.1) • Horribly boring • Difficult to discern critical needs from desires. • Requirements may sometimes be dictated by a single person (depending on size of application, this may not be good! – You will get ‘that’ persons views and biases. • ‘Analysis paralysis’

5. Requirements • Merely something that the computer application does for its users. A value or feature! • Sum of requirements => scope of application • Add requirements? Scope increases… • Scope creep! • Document system functions in the users’ language and from users’ perspective! • Requirements indicate specific system responses to user inputs (interactions).

6. Requirements • Remember: • Requirements documents user functions and application features needed by user – (typically end-user especially. But there are lots of stakeholders!) • Analysis is a ‘logical solution’ that satisfies requirements – NO implementation details. • Design – impose physical solutions / constraints; supports Construction. • Testing, Deployment, Maintenance • Important to note that many methodologists like to lump Requirements Analysis and Specification together. (Not always a great idea…)

7. Heuristic • Requirements are the ‘whats’ of an application. • Desired functional and non-functional features. • Design is the ‘hows’ of an application. • specific classes will be used. • database / file system; • Heavily architecturally-oriented – artifacts, layers… • platforms, middleware, programming language, networking approach, etc. • Again, HOW do we, as developers, satisfy the ‘whats’ of the system!!

8. Requirements and Design • VERY different activities • Require different mindsets; different people • Requirements – understanding the problem at hand • Design – solving the problem • Clearly, cannot design a solution until the problem has been identified, documented and understood!

9. Functional and Non-Functional Requirements • Functional requirements are what the users need for the system to work. • Functions and features • “Need to add, change and delete transactions” • “Need to generate ‘this’ report and ‘that’ report…” • Non-functional requirements • Items like performance, scalability, backup and recovery, security, analysis/design mechanisms… • (handled in later versions of Use Cases) - Focused

10. Requirements Gathering Definition and Specification • Clearly, ‘Requirements Gathering’ – bringing together of requirements • ‘Definition’ is documenting, organizing, capturing and modeling the requirements, and • ‘Specification’ is the document (artifact) produced. (Use Use Case Model for Requirements (used Business Use Case Model & Business Object Model for Business Modeling)) • Reality Check: Systems more complex? More effort needed; fall in larger numbers, and more likely to fall and with major impacdts…

11. Challenges of Requirement Gathering • Users do NOT know what they want. • A very complicated question • Too many variables • Conflicts in performing today’s job and in shaping a new system. • Requirements change dynamically… • Remember: it is the users who must be satisfied! • Sample problems / claims about users: • Contrary view: Users DO know what they want – Difficult to capture these in a specification! • Difficult to capture unambiguously and model…

12. User Problems / Claims • Users don’t understand what they want • Users won’t commit to a set of written requirements • Users insist on new requirements after the cost and schedule have been fixed • Communication with users is slow and often ‘low’ • Users often do not participate in reviews or are incapable of doing so • Users are technically unsophisticated • Users don’t understand the software development process • etc.

13. What can We do? • Understand the User’s divided attentions… • Establish a relationship with your users • Make it personal • They will make more meetings, reviews, and answer more questions • Make project more visible • Escalate the importance of system to senior level executives, if possible • If seniors are “aware,” more likely users will attend requirement sessions, interview sessions, etc. • Be respectful of others’ time! • Batch questions, interviews together…

14. Requirements Documentation • Must create document and confirm with users. • Difficult to do with older tools, such as ERDs, DFDs, DLTs, Structure Charts, etc. • Problems between those creating the requirements specification and designers. • For requirements people who are ‘designers at heart’ – tend to tell designers ‘how’ to implement! • Can happen when developers are ‘off site’ and removed from the requirements gatherers and users. • Also happens if requirements analysts don’t trust designers and developers to make correct decisions.

15. More on Requirements Gathering and Specification • Have reviews to avoid conflict • Try to avoid conflicting requirements • The larger the volume, the less likely project will succeed. • Establish requirements traceability!! • Requirements should be traceable throughout the effort back to requirements specification.

16. Traceability • Analyst/designer – Where did this requirement come from? Within a class, what requirement does this method satisfy? Where is it specified? • Developer – What specific requirements does the class you’re programming relate to? Executing this method satisfies what requirement(s)? • Much more details on class contents (parameters…) • Heavily architecture-dependent; Oftentimes multiple components are needed to satisfy individual requirements. • Tester – When you execute this ‘test case,’ what exact requirement are you testing for? Can you find it in the requirements specification?

17. Standard Approaches (1 of 4) • User Interviews: • Trying to learn how users do their jobs now, how they expect their jobs to change, and typical problems they encounter now. • Different people at different levels – conflict • We get ‘their’ perspective • Customer, end-user, client, etc… • User Questionnaires – lots of pros/cons. Many ‘types’ and ways to administer… Lots of philosophies on creating types of questions – open-ended, closed, etc. And methods to evaluate the responses (if any…) • Web pages – org chart; mission; services… • Annual Reports – what’s going on? Marketing… • Newsletters – See local happenings; sometimes more global

18. Standard Approaches (2 of 4) • Joint Requirements Planning Sessions (JRP) • Conduct all interviews at same time in same room. • All key people brought together. • Have facilitator and a scribe and projectors, and diagramming software… • Focus is on WHAT the system • Have representatives of all key stakeholders • High-level topics (in JRP) are first: critical success factors, strategic opportunities, vision, risks, business rules, … • Functional/non-functional requirements identified, documented, and prioritized. OWNERSHIP!! • Normally conducted off-site. • Artifact: the document produced: a list of requirements. (List? Ech!)

19. Standard Approaches (3 of 4) • Requirements Lists • Problems with Requirements Lists • Most people detest requirement lists! • Replace with Use Cases, Use Case diagrams, and business rules replace the requirements lists. (Next Chapter) • But not always; Requirements lists are sometimes used at very early stages for stakeholders and clearly differentiating sub-requirements (alternatives, exceptions, …) • Review sample requirements lists: pp. 16-17.

20. Standard Approaches (4 of 4) • Prototypes • Pros: • Very popular in mid 1980s • Are mock-ups of screens and/or windows • Primarily used do define user interfaces!!! • Great user-interface prototyping tools available – e.g. VB is super for UI capture. • Extremely conducive to communications between user groups and developers. • Early changes to screens set stage for fewer changes later and reduced overall costs! • Greatly facilitates stakeholder acceptance later…

21. Standard Approaches (4 of 4) • Prototypes • Cons: • But, some pay more attention to screen than to functionality. • Executives sometimes fail to realize that prototype is not a working system. • Want it right away • A throwaway – Get buy-in up front on the throw-away – unless the development strategy (small systems) is to hone the prototype into a compliant application). • Prototypes imply more is ‘done’ than is done. • Only represent front end (presentation) and do not usually represent the business rules. • At best (but very good!) a great way to determine the user interface specification.

22. Most popular way to capture functional requirements is the Use Case: a widely-adhered to technology. • Enter: Use Cases