SOFTWARE REQUIREMENTS ANALYSIS SWRA Instructor Dr Hany H

SOFTWARE REQUIREMENTS ANALYSIS (SWRA) Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

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

What is Requirements Engineering ? n Requirements Engineering

What is Requirements Engineering? n n 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

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

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

What is Requirements Engineering? n 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. n 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.

What is Requirements Engineering? Requirements Specification n Specification key practice is to write down the requirements in some accepted, structured format as you gather and analyze them. n The objective of requirements development is to communicate a shared understanding of the new product among all project stakeholders. n 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)

What is Requirements Engineering? n n Requirements 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

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

Introduction to Requirements Analysis and Specification: The SRS Document n n n 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 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

Introduction to Requirements Analysis, The SRS Doc n n n 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)

Introduction to Requirements Analysis, The SRS Doc n n n 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

Introduction to Requirements Analysis, The SRS Doc n n n 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

Introduction to Requirements Analysis, The SRS Doc n n 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

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

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

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

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

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

The Structured Analysis Model

The Object-Oriented Analysis (OOA) Methodology n n 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

The Unified Modeling Language UML What is the UML? n n n 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.

UML Concepts n The UML may be used to: 1. 2. 3. 4. 5. 6. 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

Putting the UML to Work A Simple Example requirements n 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 – –

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

UML Use Case Diagrams: Defining Use Cases A use 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 n Actors are examined to determine their needs – Registrar -- maintain the curriculum – Professor -- request roster – Student -- maintain schedule – Billing System -- receive billing information from registration Request Course Roster Maintain Curriculum Maintain Schedule n

Documenting Use Cases n n n 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

Example: Maintain Curriculum Use case Flow of Events n n n 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.

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

Use Case Diagram: Includes and Extends Use Case Relationships n 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 <<includes>> Register for courses <<includes>> Maintain curriculum Logon validation

Use Case Realizations (Object Interaction diagrams) The use case diagram presents an outside view of the system n 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) n Two types of interaction diagrams n – – Sequence diagrams Collaboration diagrams

UML: Sequence Diagram n A sequence diagram displays object interactions arranged in a time sequence registration form : Student registration manager math 101 section 1 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) Time

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

Class Diagrams: Defining Classes Schedule. Algorithm Registration. Form Registration. Manager Course Student. Info Professor. Info Course. Offering

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

Class Diagrams: Defining Class Attributes n n 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 Course. Offering number location time

Class Diagrams: Class Relationships n n n 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

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

Class Diagrams: with Relationships Schedule. Algorithm Registration. Form Registration. Manager add. Student(Course, Student. Info) Course name number. Credits Student. Info open() add. Student(Student. Info) name major Professor. Info name tenure. Status Course. Offering location open() add. Student(Student. Info)

UML: The State of an Object n A state transition diagram shows – – – n 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

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