SOFTWARE REQUIREMENTS ANALYSIS (SWRA)

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

13. 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)

14. 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

15. 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

16. 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

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

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

19. 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

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

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

22. The Structured Analysis Model

23. 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

24. 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.

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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.

31. 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

32. <<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

33. 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

34. 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

35. 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

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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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