1 / 43

SOFTWARE REQUIREMENTS ANALYSIS (SWRA)

SOFTWARE REQUIREMENTS ANALYSIS (SWRA). Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU. OUTLINE. Introduction to Requirements Engineering Introduction to Requirements Analysis and Specifications (SRS) document

ethelk
Télécharger la présentation

SOFTWARE REQUIREMENTS ANALYSIS (SWRA)

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. SOFTWARE REQUIREMENTS ANALYSIS (SWRA) Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

  2. OUTLINE • Introduction to Requirements Engineering • Introduction to Requirements Analysis and Specifications (SRS) document • Introduction to Object-Oriented Analysis techniques using UML

  3. What is Requirements Engineering ? • Requirements Engineering

  4. What is Requirements Engineering? • Requirements Management: Requirements management activities include evaluating the impact of proposed changes, tracing individual requirements to downstream work products, and tracking requirements status during development • Several Requirements management tools are available in industry

  5. What is Requirements Engineering? • Major Requirements Management Tools: 1. Caliber-RM by Technology Builders, Inc.; www.tbi.com 2. RequisitePro by Rational Software Corporation; www.rational.com 3. RTM Workshop by Integrated Chipware, Inc.; www.chipware.com

  6. What is Requirements Engineering? • Requirements Elicitation • is the process of gathering the different types of requirements from suitable stakeholders. • Business requirements describe why the product is being built and identify the benefits for both the customers and the business. • User requirements, describe the tasks or business processes a user will be able to perform with the product. (Developing use-cases) • Functional requirements describe the specific system behaviors that must be implemented (Developing usage scenarios) • Non-functional requirements, describe the non-functional features such as quality attributes of Reliability, Performance, availability, and maintainability.

  7. What is Requirements Engineering? • Requirements analysis: Requirements analysis includes decomposing high-level requirements into detailed functional requirements, constructing graphical requirements models or logical models (structured Analysis models, or Object-Oriented Analysis models) (for developers), and building prototypes. • Analysis models and prototypes provide alternative views of the requirements, which often reveal errors and conflicts that are hard to spot in a textual SRS.

  8. What is Requirements Engineering? Requirements Specification • Specification key practice is to write down the requirements in some accepted, structured format as you gather and analyze them. • The objective of requirements development is to communicate a shared understanding of the new product among all project stakeholders. • Historically, this understanding is captured in the form of a textual SRS document written in natural language, augmented by appropriate analysis models. (to be discussed in detail)

  9. What is Requirements Engineering? • Requirements Verification Verification involves evaluating the correctness and completeness of the requirements, to ensure that a system built to those requirements will satisfy the users’ needs and expectations. The goal of verification is to ensure that the requirements provide an adequate basis to proceed with design • Prototyping (or executable specifications) is a major technique used in verification. Examples include GUI development for user requirements verification, and Formal requirements specification environments

  10. OUTLINE • Introduction to Requirements Engineering • Introduction to Requirements Analysis and Specifications (SRS) document • Introduction to Object-Oriented Analysis techniques using UML

  11. Introduction to Requirements Analysis and Specification: The SRS Document • The specification of SWRA phase in the DOD standard MIL-STD-498 also focuses on analyzing the requirements and developing a logical model for each computer software configuration item (CSCI) • The output of this phase is the the Software Requirements Specification (SRS) document (See Table 1, section 3.1.3 of the notes) • The SRS starts in the first section by identifying the scope of the CSCI, presenting a system overview, and a document overview

  12. Introduction to Requirements Analysis, The SRS Doc • The second section lists the number, title, revision, date, and source of all documents referenced in this specification. • The third section, the largest and most important section contains the detailed specifications of the CSCI as follows • The states and modes of operation of the CSCI are clearly specified (e.g., idle, ready, active, post-use analysis, training, degraded, emergency, backup, wartime, peacetime)

  13. Introduction to Requirements Analysis, The SRS Doc • Each requirement or group of requirements in this specification must be correlated to the states and modes in which they belong. • The SRS specifies the capability or functionality requirements in terms of control processing and data processing capabilities of the CSCI (e.g., data flow/control flow diagrams are used in SART) • Requirements pertaining to the CSCI's external interfaces may be presented in the SRS or in one or more Interface Requirements Specifications (IRSs) documents referenced from the SRS

  14. Introduction to Requirements Analysis, The SRS Doc • Internal interfaces and data requirements between capabilities of the CSCI must be specified • Non-functional requirements such as safety, Security and privacy requirements, and quality factors such as reliability and availability requirements must also be specified along with the environmental requirements • Computer resource requirements in terms of HW, SW, and Communication resources must be specified

  15. Introduction to Requirements Analysis, The SRS Doc • Design and implementation constraints (e.g., required databases,particular design or implementation standards or languages, Flexibility to changes in technology, and expendability) • Precedence and criticality of requirements listed in the previous subsections • Section 4 specifies the qualification methods used to ensure that the requirement in section 3 has been met. • In Section 5, Traceability is established from each CSCI requirement in this specification to specific components and sections in the SSS and SSDD docs

  16. Example of an SRS Document THE INSTRUMENT A DATA PROCESSING UNIT FOR THE COMPANY X GAMMA RAY DETECTOR EXPLORER Prepared for NASA Contract

  17. OUTLINE • Introduction to Requirements Engineering • Introduction to Requirements Analysis and Specifications (SRS) document • Introduction to Object-Oriented Analysis techniques using UML

  18. Structured Analysis Vs Object-Oriented Analysis The Structured Analysis model • The SA model is divided into two main types of elements; data processing functions and control functions • Data processing functions process input data, produce output data and controls, and send control information to the controllers • Control functions process input controls, activate or deactivate data processing functions thr’ control signals, and also produce output controls

  19. The Structured Analysis Methodology Uses Data Flow/Control Flow diagrams and state diagrams to model the functional requirements

  20. The DFD/CFD model of The Automatic Teller Machine (ATM) Example

  21. The Structured Analysis Model

  22. The Object-Oriented Analysis (OOA) Methodology • Based on describing the logical model of the system and the environment as a set of interacting objects • Defines the external objects (actors) interacting with the system as well as the internal objects that the system must contain • Defines the static architecture of objects and the behavioral interactions between them • Defines the internal behavior of objects

  23. The Unified Modeling LanguageUML What is the UML? • UML stands for Unified Modeling Language • The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system • It can be used with all processes, throughout the development life cycle, and across different implementation technologies.

  24. UML Concepts • The UML may be used to: • Display the boundary of a system & its major functions using use cases and actors • Illustrate use case realizations with interaction diagrams • Represent a static structure of a system using class diagrams • Model the behavior of objects with state transition diagrams • Reveal the physical implementation architecture with component & deployment diagrams • Extend your functionality with stereotypes

  25. Putting the UML to WorkA Simple Example Example requirements • The ESU University wants to computerize their registration system • -The Registrar sets up the curriculum for a semester • -One course may have multiple course offerings • -Students select 4 primary courses and 2 alternate courses • -Once a student registers for a semester, the billing system is notified so the student may be billed for the semester • -Students may use the system to add/drop courses for a period of time after registration • -Professors use the system to receive their course offering rosters • -Users of the registration system are assigned passwords which are used at logon validation

  26. Professor Registrar Student UML Use Case Diagrams: Defining Actors (External objects) • An actor is someone or some thing that must interact with the system under development Billing System

  27. Request Course Roster Maintain Schedule Maintain Curriculum UML Use Case Diagrams: Defining Use Cases • A use case captures the user requirements, it is a pattern of behavior the system exhibits • Each use case is a sequence of related transactions performed by an actor and the system in a dialogue • Actors are examined to determine their needs • Registrar -- maintain the curriculum • Professor -- request roster • Student -- maintain schedule • Billing System -- receive billing information from registration

  28. Documenting Use Cases • A flow of events document is created for each use cases • Written from an actor point of view • Details what the system must provide to the actor when the use cases is executed • Typical contents • How the use case starts and ends • Normal flow of events • Alternate flow of events • Exceptional flow of events

  29. Example: Maintain Curriculum Use case Flow of Events • This use case begins when the Registrar logs onto the Registration System and enters his/her password. The system verifies that the password is valid (E-1) and prompts the Registrar to select the current semester or a future semester (E-2). The Registrar enters the desired semester. The system prompts the Registrar to select the desired activity: ADD, DELETE, REVIEW, or QUIT. • If the activity selected is ADD, the S-1: Add a Course subflow is performed. • If the activity selected is DELETE, the S-2: Delete a Course subflow is performed. • If the activity selected is REVIEW, the S-3: Review Curriculum subflow is performed. • If the activity selected is QUIT, the use case ends.

  30. Request Course Roster Maintain Schedule Billing System Professor Registrar Student Maintain Curriculum UML: Use Case Diagram • Use case diagrams are created to visualize the relationships between actors and use cases

  31. <<includes>> Register for courses <<includes>> Logon validation Maintain curriculum Use Case Diagram: Includes and Extends Use Case Relationships • As the use cases are documented, other use case relationships may be discovered • The includes relationship shows behavior that is common to one or more use cases • An extends relationship shows optional behavior

  32. Use Case Realizations(Object Interaction diagrams) • The use case diagram presents an outside view of the system • Interaction diagrams capture the functional requirements and describe how use cases are realized as interactions among societies of objects (objects interact to accomplish a function of the system) • Two types of interaction diagrams • Sequence diagrams • Collaboration diagrams

  33. registration registration math 101 math 101 : Student section 1 form manager 1: fill in info 2: submit 3: add course(joe, math 01) 4: are you open? 5: are you open? 6: add (joe) 7: add (joe) UML: Sequence Diagram • A sequence diagram displays object interactions arranged in a time sequence Time

  34. UML Class Diagrams • A class diagram shows the existence of classes and their relationships in the logical view of a system • UML modeling elements in class diagrams • Classes and their structure and behavior • Association, aggregation, and inheritance relationships • Multiplicity and navigation indicators • Role names

  35. ScheduleAlgorithm RegistrationForm RegistrationManager Course StudentInfo ProfessorInfo CourseOffering Class Diagrams:Defining Classes

  36. registration registration form manager RegistrationManager 3: add course(joe, math 01) addCourse(Student,Course) Class Diagrams:Defining Class Operations • The behavior of a class is represented by its operations • Operations may be found by examining interaction diagrams

  37. CourseOffering number location time Class Diagrams:Defining Class Attributes • The structure of a class is represented by its attributes • Attributes may be found by examining class definitions, the problem requirements, and by applying domain knowledge From the requirements statements Each course offering has a number, location and time

  38. Class Diagrams:Class Relationships • Relationships provide a pathway for communication between objects • Object interaction diagrams are examined to determine what links (dependencies) between objects need to exist to accomplish the behavior -- if two objects need to “talk” there must be a link or a dependency between them • Three types of relationships are: • Association • Aggregation • Inheritance

  39. Registration Math 101: Manager Course 3: add student(joe) RegistrationManager Course Class Diagrams:Finding Class Relationships • Relationships are discovered by examining interaction diagrams • If two objects must “talk” there must be a pathway for communication

  40. ScheduleAlgorithm RegistrationForm RegistrationManager addStudent(Course, StudentInfo) Course name numberCredits StudentInfo open() name addStudent(StudentInfo) major ProfessorInfo CourseOffering name tenureStatus location open() addStudent(StudentInfo) Class Diagrams:with Relationships

  41. UML: The State of an Object • A state transition diagram shows • The life history of a given class • The events that cause a transition from one state to another • The actions that result from a state change • State transition diagrams are created for objects with significant dynamic behavior

  42. Add student[ count < 10 ] Add Student / Set count = 0 Initialization Open do: Initialize course Cancel Cancel [ count = 10 ] Canceled do: Notify registered students Closed Cancel do: Finalize course State Transition Diagram entry: Register student, And Increment count

More Related