1 / 97

Chapter 3 Understanding Requirements

Chapter 3 Understanding Requirements. Requirements Vision Use-Case Modeling Software Requirements Specification Requirements Management Case Study and Project. Requirements. 3.1 Requirements. What is Requirements Types of Requirements Requirements Documents.

cuyler
Download Presentation

Chapter 3 Understanding Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 3 Understanding Requirements • Requirements • Vision • Use-Case Modeling • Software Requirements Specification • Requirements Management • Case Study and Project

  2. Requirements

  3. 3.1 Requirements • What is Requirements • Types of Requirements • Requirements Documents

  4. What is requirement? • Requirements are capabilities and conditions to which the system (and more broadly, the project) must conform. [JBR99]. • The purpose of Requirements is: • To provide system developers with abetter understanding of the system requirements. • To define the boundaries of (delimit) the system. • To provide a basis for planning the technical contents of iterations. • To provide a basis for estimating cost and time to develop the system. • To define a user-interface for the system, focusing on the needs and goals of the users.

  5. Requirements • Factors on challenged software projects • 37% of factors related to problems with requirements,

  6. Requirements Management • Requirements management is a systematic approach to • eliciting, organizing, and documenting the requirements of the system • establishing and maintaining agreement between the customer and the project team on the changing requirements of the system. • Keys to effective requirements management include • maintaining a clear statement of the requirements, along with applicable attributes for each requirement type • traceability to other requirements and other project artifacts.

  7. Types of Requirements– FURPS+ • Functional • features, capabilities, security. • Usability • human factors, help, documentation. • Reliability • frequency of failure, recoverability, predictability. • Performance • response times, throughput, accuracy, availability, resource usage. • Supportability • adaptability, maintainability, internationalization, configurability.

  8. Types of Requirements– FURPS+ • The "+" in FURPS+ indicates ancillary and sub-factors, such as: • Implementation • resource limitations, languages and tools, hardware, ... • Interface • constraints imposed by interfacing with external systems. • Operations • system management in its operational setting. • Packaging • Legal • licensing and so forth.

  9. Types of Requirements– RUP • Requirements are categorized as functional (behavioral) or non-functional (everything else); • Functional Requirements • Functional requirements are explored and recorded in • the Use-Case Model • the system features list of the Vision artifact. • Non-functional Requirements • Other requirements can be recorded in the use cases they relate to, or in the Supplementary Specifications artifact.

  10. Requirement Documents • Vision • The Vision artifact summarizes high-level requirements that are elaborated in these other documents. • The Vision is a general vision of the core project's requirements, and provides the contractual basis for the more detailed technical requirements. • Include: • Problem Statement • User or Stakeholder Descriptions • Product Overview • Features • Constraints

  11. Requirement Documents • SRS (Software Requirements Specification) • Functional requirements • Use case Model • Non-functional requirements • Supplementary Specification • Glossary • records and clarifies terms used in the requirements. • also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth • User-Interface Prototype Prototypes are a mechanism to clarify what is wanted or possible.

  12. Requirement Artifacts in UP

  13. Vision

  14. 3.2 Vision • Introduction • Template • Example • How to develop Vision

  15. Vision - Introduction • The Vision document provides • a complete vision for the software system under development and supports the contract between the funding authority and the development organization. • The vision document is • written from the customers' perspective, • focusing on the essential features of the system and acceptable levels of quality. • The Vision should include • a description of what featureswill be included as well as those considered but not included. • It should also specify operational capacities (volumes, response times, accuracies), user profiles (who will be using the system), and inter-operational interfaces with entities outside the system boundary, where applicable. • The Vision document provides the contractual basis for the requirements visible to the stakeholders.

  16. Vision - Introduction • The Vision document • is created early in the inception phase, and • it is used as a basis for the Business Case and the first draft of the Risk List • The Vision document • serves as input to use-case modeling, and • is updated and maintained as a separate artifact throughout the project.

  17. Vision - Introduction • Purpose of Vision • Gain agreement on what problems need to be solved. • Identify stakeholders to the system. • Define the boundaries of the system. • Describe primary features of the system.

  18. Vision - Template for small project • 1. Introduction • 2.  Positioning           • 2.1     Problem Statement       • 2.2     Product Position Statement      • 3.  Stakeholder and User Descriptions   • 3.1     Stakeholder Summary      • 3.2     User Summary • 3.3 Key High-Level Goals and Problems of the Stakeholders • 3.4 User-Level Goals      • 3.5     User environment 

  19. Vision - Template for small project • 4.  Product Overview       • 4.1     Product Perspective      • 4.2     Assumptions and Dependencies      • 5.  Product Features          • 5.1     <aFeature>      • 5.2     <anotherFeature>      • 6.  Other Requirements and Constraints      

  20. Vision - Commentary to Template • Problem Statement       • Provide a statement summarizing the problem being solved by this project. • The following format may be used:

  21. Vision - Commentary to Template • Product Position Statement • Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. • The following format may be used:

  22. Vision - Commentary to Template • User Summary • Present a summary list of all identified users. • The following format may be used:

  23. Vision - Commentary to Template • Product Perspective       • This subsection puts the product in perspective to other related products and the user’s environment. • If the product is independent and totally self-contained, state it here. • If the product is a component of a larger system, then this subsection needs to relate how these systems interact and needs to identify the relevant interfaces between the systems. • One easy way to display the major components of the larger system, interconnections, and external interfaces is with a block diagram. • System context diagram • High-level deployment diagram

  24. Vision - Commentary to Template • Product Features       • Use cases are not necessarily the only way one needs to express functional requirements. • An alternative, a complementary way to express system functions is with features, or more specifically in this context, system features, • System features are high-level, terse statements summarizing system functions. • A system feature is "an externally observable service provided by the system which directly fulfills a stakeholder need" [Kruchten00]. • Features are things a system can do. • The point of system features in the Vision is • to summarize the functionality, • not decompose it into a long list of fine-grained elements. • Keep feature descriptions at a general level. • Focus on capabilities needed and why (not how) they should be implemented. • Avoid design. • It is common to organize a two-level hierarchy

  25. Vision - Commentary to Template • Other Requirements in the Vision • In the Vision, system features briefly summarize functional requirements expressed in detail in the use cases. • Likewise, the Vision can summarize other requirements (for example, reliability and usability) that are detailed in the Special Requirements sections of use cases, and in the Supplementary Specification (SS).

  26. Vision - Example • Course Registration System example • Vision 1 • NextGen example

  27. Vision - How to develop Vision • Gain agreement on the problem being solved • Identify stakeholders • Define the system boundaries • Identify constraints to be imposed on the system • Formulate problem statement • Define features of the system • Evaluate your results

  28. Vision - Checkpoints • Have you fully explored what the "problem behind the problem" is? • Is the problem statement correctly formulated? • Is the list of stakeholders complete and correct? • Does everyone agree on the definition of the system boundaries? • If system boundaries have been expressed using actors, have all actors been defined and correctly described? • Have you sufficiently explored constraints to be put on the system? • Have you covered all kinds of constraints - for example political, economic, and environmental. • Have all key features of the system been identified and defined? • Will the features solve the problems that are identified? • Are the features consistent with constraints that are identified?

  29. 3.3 Use-Case Modeling • Key Concepts • Use-Case Diagram • Use-Case Specification • Relationship between Use-case • Checkpoints

  30. Key Concepts

  31. What Is System Behavior? • System behavior is how a system acts and reacts. • It is the outwardly visible and testable activity of a system • System behavior is captured in use cases. • Use cases describe the system, its environment, and the relationship between the system and its environment.

  32. What Is a Use-Case Model? • A model that describes a system’s functional requirements in terms of use cases • A model of the system’s intended functionality (use cases) and its environment (actors) View Report Card Register for Courses Student Login

  33. What Are the Benefits of a Use-Case Model? • Used to communicate with the end users and domain experts • Provides buy-in at an early stage of system development • Insures a mutual understanding of the requirements • Used to identify • Who interacts with the system and what the system should do • The interfaces the system should have • Used to verify • All requirements have been captured • The development team understands the requirements

  34. Major Concepts in Use-Case Modeling • An actor represents anything that interacts with the system. • A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. Actor Use Case

  35. What Is an Actor? • Actors are not part of the system. • Actors represent roles a user of the system can play. • They can represent a human, a machine, or another system. • They can actively interchange information with the system. • They can be a giver of information. • They can be a passive recipient of information. Actor Actors are EXTERNAL.

  36. Useful Questions in Finding Actors? Actor • Who will supply, use, or remove information? • Who will use this functionality? • Who is interested in a certain requirement? • Where in the organization is the system used? • Who will support and maintain the system? • What are the system’s external resources? • What other systems will need to interact with this one?

  37. Focus on the Roles ? • An actor represents a role that a human, hardware device, or another system can play.

  38. A User May Have Different Roles Charlie as student Charlie Student Charlie as professor Professor

  39. Practice: Find the Actors • In the Course Registration System Requirements document, read the Problem Statement for the Course Registration case study. • As a group, identify the following • Actors • Description of the actor

  40. Practice: Solution Billing System Student Course Catalog Professor Registrar A person who is registered to take courses at the University The external system responsible for student billing The unabridged catalog of all courses offered by the University A person who is teaching classes at the University The person who is responsible for the maintenance of the course registration system

  41. What Is a Use Case? Use Case • A sequence of actions a system performs that yields an observable result of value to a particular actor

  42. Use Cases and Actors Use Case Actor • A use case models a dialog between actors and the system. • A use case is initiated by an actor to invoke a certain functionality in the system. Communicates Association

  43. How to Find Use Cases • Answer the following questions to find use cases. • For each actor you have identified, what are the tasks the system would be involved in? • Does the actor need to be informed about certain occurrences in the system? • Will the actor need to inform the system about sudden, external changes? • What information must be modified or created in the system?

  44. Naming the Use Case Register for Courses Login Maintain Student Information • The name indicates what is achieved by its interactions with the actor(s). • The name may be several words in length. • No two use cases should have the same name.

  45. Use-Case Diagram

  46. Use case diagram • Captures system functionality as seen by users • Built in early stages of development • Purpose • Specify the context of a system • Capture the requirements of a system • Validate a system’s architecture • Drive implementation and generate test cases • Developed by analysts and domain experts

  47. How Would You Read This Diagram? View Report Card Student Maintain Professor Information Register for Courses Course Catalog Login Maintain Student Information Select Courses to Teach Registrar Professor Submit Grades Close Registration Billing System

  48. Use Case Diagram - Example Project Management Normal User Project Manager Query User Authentication User Management Administrator System Configuration Development Manager

  49. Use-Case Specification

  50. Use-Case Specifications Use-Case Model Actors Use Cases ... Use-Case Specifications • Name • Brief description • Flows of Events • Relationships • Activity diagrams • Use-Case diagrams • Special requirements • Pre-conditions • Post-conditions • Other diagrams

More Related