1. (1) Requirements Analysis and Specification Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii johnson@hawaii.edu

2. (2) Definitions Requirements Analysis: The process of studying and analyzing the customer and user needs to arrive at a definition of software requirements. Requirements Specification: A document that clearly and precisely describes each of the essential requirements of the software and its external interfaces.

3. (3) Many different approaches When do we do requirements analysis? Before starting implementation? Before and during implementation? How should we specify the requirements? Through structured text? Through formal notations and models? Through informal note cards and acceptance tests? When should we create the requirements specification? Before starting implementation? Simultaneously with implementation? Don’t do it at all?

4. (4) Some Schools of Thought The "Traditionalists" Upfront requirements prior to implementation Well defined, structured process and products 30 years of experience for data processing domain The "Model Driven Analysis/Architecture/Development" folks Based upon UML notation Object-oriented Goal: semi-formal, semi-executable models that can be kept in sync with code The "Agilists" Minimal, just-in-time requirements Requirements artifacts "thrown away" once code is available

5. (5) A perspective on the "traditionalist" approach

6. (6) Traditionalist Goals Generate a "software requirements specification" prior to implementation that provides enough details on system requirements to support: contractual negotiation with a contractor detailed specifications for coding by an independent contractor detailed specifications for testing by an independent contractor end-to-end project planning and estimation

7. (7) Processes Requirements elicitation Identifying stakeholders, obtaining "raw" requirements from them via observation and interviews. Methods: Ethnography, Protocol Analysis, JAD Requirements analysis Link customer needs to product capabilities Develop use cases (end-to-end scenarios) Create logical and data models Methods: QFD, SCRAM, SSAD Requirements validation and prioritization Resolve inconsistencies, multiple viewpoints Methods: CORE, WinWin

8. (8) SRS Template 1. Introduction Purpose, intended audience, conventions, scope 2. Overall description Product perspective, features, users, operating environment, design constraints, documentation, assumptions 3. System features 4. External interfaces User, Hardware, Software, Communication 5. Nonfunctional requirements Performance, Safety, Security, Quality Appendix A: Glossary Appendix B: Analysis Models (Functional, Data, Use Case)

9. (9) How do we fill out the template? It’s ridiculously easy to create a WORTHLESS software requirements specification by mindlessly or haphazardly filling out the template to create an SRS that: Does not identify all needed requirements Specifies requirements that are not needed. Specified requirements are ambiguous Specified requirements conflict with each other Better: perform various analyses of the system to “discover” the true requirements Functional Analysis Data Flow Analysis Data Modeling Use Case Analysis

10. (10) Functional Analysis

11. (11) Functional Analysis Goal: Establish the functions required and the system boundary Procedure: Express functions in terms of converting inputs into outputs Break down top-level function into a set of sub-functions Draw a block diagram illustrating relationships between functions

12. (12) Functional Analysis Model (top-level)

13. (13) Functional Analysis Model

14. (14) Data Flow Analysis

15. (15) Data Flow Analysis Models processes and dataflows without sequence information. Consists of context diagram and decomposable dataflow diagrams. Describes I/O (data that flows across system or subsystem boundaries) External entities and resources Data stores

16. (16) Context Diagram

17. (17) Level 0 Diagram

18. (18) Enroll Students (Process 4)

19. (19) Data Modeling

20. (20) Logical Data Modeling Top-level "logical" data base design, including: Specify all entities and relationships among them. All attributes for each entity are specified. The primary key for each entity specified. Foreign keys (keys identifying the relationship between different entities) are specified. Normalization if necessary

21. (21) Physical Data Modeling Convert the logical data model to one that can be implemented in a database: Specify all tables and columns. Foreign keys are used to identify relationships between tables. Denormalization may occur based on user requirements. Physical considerations may cause the physical data model to be quite different from the logical data model.

22. (22) Use Case Analysis

23. (23) Use Case Analysis A use case is a single task, performed by the end user of a system, that has some useful outcome. A collection of use cases provides a perspective on the dynamic behavior of the proposed system. Use cases contrast with functional and data analysis, which provide perspectives on the static nature of the system.

24. (24) Goals of Use Cases 1.Develop an increased understanding of the problem and the user interface. 2.Communicate with the end users to make sure we're really solving their problems. 3.Organize the dynamic behavior of the design (and the resulting program) to reflect the actual business model in the user's mind. In other words, assure that the program actually does something useful for a real user. 4.Provide a road map and organizational framework for the actual development process.

25. (25) Potential Use Case Components Name user-centric "Make a deposit" Description What is accomplished Desired outcome What is the useful outcome Basic actions Details of use case User goals Why the user might do this Participants/Roles What role(s) are being taken Dependencies Subcases, precedes, follows, is/a, etc. Preconditions State that must exist before the use case Postconditions State what must exist after the use case Business rules Any relevent rules

26. (26) Example Use Case Name: Enroll in Seminar Identifier: UseCase-17 Description: Enroll an existing student in a seminar for which she is eligible Preconditions: The student is registered at the University Postconditions and desired outcome: The student will be enrolled in the course she wants if she is eligible and room is available.

27. (27) Example Use Case (cont) Basic course of action: The use case begins when a student wants to enroll in a seminar. The student inputs her name and student number into the system via screen UI23:Security Login Screen. The system verifies that the student is eligible to enroll in seminars at the university according to business rule BR129: Determine Eligibility to Enroll [Alt Course A: Student not eligible to enroll] The system displays screen UI32:Seminar Selection Screen, which indicates the list of available seminars.

28. (28) Example Use Case (cont.) The student indicates the seminar in which she wants to enroll [Alt Course B: The student decides not to enroll] : The system prints the enrollment statement. The use case ends when the student takes the printed statement. Alt Course A: Student not eligible to enroll : Alt Course B: The student decides not to enroll.

29. (29) Use Case Description Tips The use case makes references to specific screens and reports. The use case references business rules Each use case step reflects a single activity. Use case steps are written in the active voice. Alternate course of actions are infrequently used paths of logic.

30. (30) Summary of "Traditionalist" approach Create accurate, complete, internally consistent specification of system requirements. Functional, Data Flow, Data Modeling, and Use Case analysis can help ensure completeness. If successful, SRS can be "handed off" to a subcontractor for implementation. used as the basis for price/schedule negotiation.

31. (31) Model Driven Analysis/Development

32. (32) MDA/MDD Benefit of traditionalist approach Creates various “models” of the proposed system Problem with traditionalist approach Models are paper-based, “thrown out” as soon as implementation is underway. Large cost for very short-term use Model-driven analysis/development: Can we create models/abstractions of the system and its requirements that “survive” and “coexist” with implementation?

33. (33) MDA Goals Separate domain concerns from platform concerns. Improve communication between stakeholders by using notation more natural to domain. Increase flexibility by allowing retargeting to different technologies. Deliver systems faster by enabling automated generation of systems from abstractions. Improve quality by decreasing manual implementation of system from specifications.

34. (34) Example: Inteq MDA Framework Note the presence of backward links! High level models should remain in sync with the implementation throughout the life of the system.

35. (35) Model Driven Architecture (MDA) Trademark of Object Management Group Provides an “open, vendor-neutral approach to the challenge of business and technology change. Specifies “Platform Independent Models” (PIMs) that can be automatically translated into “Platform Specific Models” (PSMs) for.NET, J2EE, Corba, etc. PIMs specify business functionality and behavior separate from the technology- specific code that implements it. Key representations: UML, MOF, CWM - Unified Modeling Language - Meta-Object Facility - Common Warehouse Metamodel

36. (36) MDA Example http://www.omg.org/mda/mda_files/OMG-Information-Day-Sims_01-01.pdf

37. (37) UML (OMG Specification) The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."

38. (38) UML Notations Use Case Model: Describes boundary and interactions between system and users. Interaction Model: Describes how objects interact with each other. State (Dynamic) Model: State charts describe the states that classes assume over time. Activity graphs represent workflow Logical (Class) Model: Describes classes and objects in the system. Component (Physical) Model Describes hardware and software components Deployment Model: Describes physical architecture and how components map to it.

39. (39) UML Examples: Class Diagram

40. (40) UML Examples: Sequence Diagram

41. (41) UML Example: Collaboration Diagram

42. (42) UML Example: Detailed Class Diagram

43. (43) MDA/MDD summary Approach is certainly promising Provides abstraction (various perspectives) Provides automation (translation up/down) Reality as of 2008: not quite there yet. Many expensive commercial tools ArgoUML (most popular open source UML tool) Eclipse integration through “Eclipse Modeling Framework”.

44. (44) The Agilists

45. (45) Agile Development Both traditional and model-driven approaches stress “Big Up Front Requirements/Design” There is evidence that this leads to problems: A 2001 study performed by M. Thomas in the U.K. of 1,027 projects showed that scope management related to attempting waterfall practices, including detailed, up-front requirements, was cited by 82 percent of failed projects as the number one cause of failure. Jim Johnson of the Standish Group notes: when requirements are specified early in the lifecycle that 80% of the functionality is relatively unwanted by the users. He reports that 45% of features are never used, 19% are rarely used, and 16% are sometimes used.

46. (46) Agile Requirements Analysis Basic ideas: Get active participation from stakeholders Use simple tools (whiteboard, etc.) Model in a “just in time” manner Don’t bother to “maintain” requirements, use them just as a means to getting to the implementation. Define requirements in small pieces The XP approach: User Stories Customer Acceptance Tests

47. (47) User Stories Similar to use cases, but not the same. Written by the customer Take the place of a requirements document Format of three sentences (or so) of text by the customer using the customer’s own terminology. Provides just enough detail so that developers can produce a reasonable estimate of the effort required to implement it. When starting to implement a User Story, you may need to do some just-in-time modeling (create a use case or UML diagram or whatever). A user story is an informal statement of a requirement. When scheduled for implementation, the customer must write a formal acceptance test which determines when the goals of the story have been fulfilled.

48. (48) Example User Story From http://www.xprogramming.com

49. (49) Card, Conversation, Confirmation Card: User stories are written on cards. They do not contain all of the information associated with the requirement. They are a “token” representing the requirement. Conversation: The requirement is communicated from customers to programmers through communication. Confirmation: The customer defines acceptance tests that shows the behavior that the system must exhibit in order for the story to be implemented correctly.

50. (50) Summary Traditionalists: Strengths: well established approach when you must “hand off” requirements to a contractor for implementation. Weaknesses: risk of incomplete/inaccurate requirements. MDA/MDD: Strengths: provides many different views of system. Weaknesses: only partial tool support. Agilists: Strengths: avoids “big up front” costs and risks. Weaknesses: - risk of incomplete/inaccurate requirements and uncontrolled development hiding behind “agile” moniker. - Certain nonfunctional attributes (security, safety) might require “big up front requirements/design”. - Not clear how to deal with distributed development.