1 / 44

Chapter 3

Chapter 3. Requirements Specifications. 3.1: The Problem. From needs to requirements Domain analysis Requirements of the environment Roles Requirements of the owners Requirements document. Requirements.

knancy
Download Presentation

Chapter 3

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 Requirements Specifications SEG2101 Chapter 3

  2. 3.1: The Problem • From needs to requirements • Domain analysis • Requirements of the environment • Roles • Requirements of the owners • Requirements document SEG2101 Chapter 3

  3. Requirements • A condition or capability needed by a user to solve a problem or achieve an objective; • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component. SEG2101 Chapter 3

  4. Requirements Specification • The collective name of descriptions used to express all kinds of requirements to the new system, which will often be collected in a document called “requirements specification”. • A specification that sets forth the requirements for a system or system components; typically included are: functional requirements, performance requirements, interface requirements, design requirements, and development requirements. SEG2101 Chapter 3

  5. Characteristics of Requirements • Unambiguous: only one semantic interpretation • Complete: all needs or requirements are included • Verifiable: possible to check if the requirement is fulfilled • Consistent: no conflict • Modifiable: necessary changes can be made without violating other attributes • Traceable: the origin of each requirement should be clear; how each requirement is taken care in the system SEG2101 Chapter 3

  6. Domain Analysis • The aim of domain analysis is to understand the problem domain independently of the particular system we intend to develop. • We do not try to draw the borderline between the system and the environment. • We focus on the concepts and the terminology of the application domain with a wider scope than future system. SEG2101 Chapter 3

  7. Activities and Results of Domain Analysis • A clear statement of purpose, i.e., objectives and goals for the new system; • A dictionary defining the common terminology and concepts of the problem domain; • Description of the problem domain from a conceptual modeling viewpoint; • An inheritance diagram showing the relationship between concepts (types). SEG2101 Chapter 3

  8. Environment SEG2101 Chapter 3

  9. Environment Requirements SEG2101 Chapter 3

  10. Roles • A user expects the system to play a certain role. • The role is what the user expects from the system. • The play is what the system provides. • If the play fits the role then the user will be happy. • Our goal is to make systems that play their roles well. SEG2101 Chapter 3

  11. Owner Requirements SEG2101 Chapter 3

  12. Priority of Design Constraints SEG2101 Chapter 3

  13. 3.2: The AccessControl System • Project related questions • Analyzing the problem domain • The user environment • Message sequence charts • Behavior projection • The owner requirements • The system structure SEG2101 Chapter 3

  14. Project Related Questions • Page 73 of book by Braek SEG2101 Chapter 3

  15. Analyzing the Problem Domain • Problem statement • Dictionary • Concept model/data model • Specification hierarchy SEG2101 Chapter 3

  16. Problem Statement Make a statement that explains the problem domain. Focus on the purpose, the essential concepts, the procedures, and rules. SEG2101 Chapter 3

  17. Dictionary Make or obtain a dictionary for the problem domain. The dictionary should be kept updated throughout the development. SEG2101 Chapter 3

  18. Concept Model • Make a static conceptual description of the problem domain using the SOON notation, ER diagrams or similar. SEG2101 Chapter 3

  19. The Access Control Domain SEG2101 Chapter 3

  20. Type Definition of User SEG2101 Chapter 3

  21. Type Definition of Access Zone SEG2101 Chapter 3

  22. Type Definition of Access Point SEG2101 Chapter 3

  23. Type Hierarchy SEG2101 Chapter 3

  24. User Environment • Context: Make a context diagram where the system is identified and the system environment is detailed. Describe communication interfaces and other relations the system will handle. SEG2101 Chapter 3

  25. System Context SEG2101 Chapter 3

  26. User Service Interface SEG2101 Chapter 3

  27. User-Service Control Interface SEG2101 Chapter 3

  28. Message Sequence Charts • Make massage sequence charts that describe the typical interaction sequences (protocols) at each layer of the interfaces. SEG2101 Chapter 3

  29. MSC for a User Accepted SEG2101 Chapter 3

  30. MSC for a User not Accepted SEG2101 Chapter 3

  31. Symbols in MSC SEG2101 Chapter 3

  32. MSC for a User Accepted (no PIN) SEG2101 Chapter 3

  33. MSC for User not Accepted (no PIN) SEG2101 Chapter 3

  34. Accepted User with PIN SEG2101 Chapter 3

  35. Behavior Projection • To derive a more complete definition of interface behavior from a set of sequence chart, one must focus on one object at a time and the interactions it is involved in. • We may conceive each vertical section as a state, and each arrow as triggering an action.  the time-line can be transformed into a sequential behavior described as transition chart (TC). SEG2101 Chapter 3

  36. Transition Charts for User Behaviors SEG2101 Chapter 3

  37. Combining Alternative User Behaviors SEG2101 Chapter 3

  38. User Role Behavior SEG2101 Chapter 3

  39. System Role Behavior SEG2101 Chapter 3

  40. Role Behavior • Define the interface behavior of each role in the system and in the environment. Use the roles as a basis for behavior synthesis and validation. SEG2101 Chapter 3

  41. Owner Requirements SEG2101 Chapter 3

  42. Sketch System Structure • Sketch the system structure using SOON or similar notations. Identify the parts that are subject to requirements. Avoid describing more than required. SEG2101 Chapter 3

  43. System Structure SEG2101 Chapter 3

  44. Local Station SEG2101 Chapter 3

More Related