CEN 4020 Software Engineering PPT4: REQUIREMENT ANALYSIS Dishant Patel Requirement is an expression of desired behavior Requirement deals with: Objects or entities state they can be in Functions that are performed to change states or object characteristics Requirement focuses on the customer needs, not on the solution or implementation WHAT ARE REQUIREMENTS? Performed by requirement or system analyst Final outcome is a Software Requirement Specification (SRS) SRS is used to communicate to other software developers of how the product is going to behave PROCESS OF CAPTURING REQUIREMENTS Functional explains required behavior in terms of required activities Nonfunctional explains some characteristic that the software must possess Fast response time Low maintenance cost Design Constraint a design decision Choice of platform Process Constraint Restriction on the techniques or resources that can be used to build the system TYPES OF REQUIREMENT Requirement Elicitation is a process where the data collection is done for the system Interviewing Stake Holders Reviewing available documents Observing the current system Brainstorming with current and potential users SOURCES OF REQUIREMENT Stakeholders consists of: Clients who pay for the software to develop Customers who buys the software Users who uses the software Domain Expert knows the problem that the software must automate Software Engineers Lawyers or Auditors take surveys to determine potential customer and future trend REQUIREMENT ELICITATION Requirement analyst have a big role in elicitation process. They have to discuss the requirement with everyone who has a stake in the system. Especially Users and Developers They dont understand each other REQUIREMENT ELICITATION HOW USERS AND DEVELOPERS VIEW EACH OTHER If Users and Developers dont communicate properly then there will be errors in the software As shown in the graph, the cost of fixing error depends on when they are detected. If Users and Developers dont come up to an agreement than the project is doomed to fail REQUIREMENT ELICITATION There are two types of requirement documentation Requirement Definition complete list of everything customer wants to achieve Requirement Specification restates the requirements as a specification of how the proposed system shall behave REQUIREMENT DOCUMENTATION Requirement Definition expresses requirements by: Describing entities of environment in which the system will be installed Describes the desired constraint on, monitoring of, or transformation of those entities REQUIREMENT DEFINITION Requirement Specification describes all input and outputs in detail, including: Source of the inputs Destination of the outputs Value ranges Data protocols Timing constraint Requirement Specification restates the required functionality in the terms of interfaces inputs and outputs REQUIREMENT SPECIFICATION Requirements defined anywhere within the environment's domain, including the system's interface Specification restricted only to the intersection between environment and system domain SPECIFICATION VS. DEFINITION Correct Consistent Unambiguous Complete Feasible Relevant Testable Traceable CHARACTERISTIC OF REQUIREMENT Its important to have standard notation for modeling, documenting and communicating decisions Modeling helps us to understand requirement thoroughly Holes in the model reveal unknown or ambiguous behavior Multiple, conflicting output to the same input reveal inconsistencies in the requirements MODELING NOTATION Entity-Relationship Diagrams- A popular graphical notational paradigm for representing conceptual models MODELING NOTATIONS Entity diagram of turnstile problem UML is a collection of notations used to document software specifications and designs UML Class Diagram of Library Problem Event Traces-A graphical description of a sequence of events that are exchanged between real-world entities Vertical line: the timeline of distinct entity, whose name appear at the top of the line Horizontal line: an event or interaction between the two entities bounding the line Time progresses from top to bottom Each graph depicts a single trace, representing one of several possible behaviors Traces have a semantic that is relatively precise, simple and easy to understand MODELING NOTATIONS Message Sequence Chart MODELING NOTATIONS State Machines - A graphical description of all dialog between the system and its environment Node (state) represents a stable set of conditions that exists between event occurrences Edge (transition) represents a change in behaviour or condition due to the occurrence of an event MODELING NOTATIONS Finite state machine model of the turnstile problem MODELING NOTATIONS UML Statechart Diagram ER diagram, event trace, state machines depict only lower-level behaviour A data-flow diagram (DFD) models functionality and the flow of data from one function to another MODELING NOTATIONS High-level Data-Flow Diagram Use Cases MODELING NOTATIONS Library use cases including borrowing a book, returning a borrowed book, and paying a library fine Formal Method Formal methods: mathematically based specification and design techniques Formal methods model requirements or software behaviour as a collection of mathematical functions or relations Functions specify the state of the system's execution, and output A relation is used whenever an input value maps more than one output value Functional method is consistent and complete MODELING NOTATIONS Decision table It is a tabular representation of a functional specification that maps events and conditions to appropriate responses or action MODELING NOTATIONS Decision table for library function borrow, return, reserve and unreserved Parnas Tables Tabular representations of mathematical functions or relations Logic Two kinds: First-order logic - comprising typed variables, constants, functions, and predicates Temporal logic - introduces additional logical connectives for constraining how variables can change value over time MODELING NOTATIONS State Machine example: Petri Nets Petri Nets - A form or state-transition notation that is used to model concurrent activities and their interaction MODELING NOTATIONS Petri net of book loan Object Constrain Language Both mathematically precise and easy for non-mathematicians to read, write, and understand MODELING NOTATIONS Z A formal requirements- specification language that structures set-theoretic definitions of variables into a complete abstract- data-type model of problem uses logic to express the pre- and post-conditions for each operation MODELING NOTATIONS PROTOTYPING REQUIREMENT Keyboard-entry- Prototype Users have to type the day, month and year Calendar-based-prototype users have to select a date, month and year in the chart Slide-bar-Based Prototype users have to slide each bar left-right to select date, month and year There are two types of approaches to prototyping: Throwaway approach- Developed to learn more about a problem or a proposed solution, and that is never intended to be part of the delivered software Allow us to write quick-and-dirty Evolutionary approach- Developed not only to help us answer questions but also to be incorporated into the final product These techniques are also known as rapid prototyping PROTOTYPING REQUIREMENTS IEEE STANDARD FOR REQUIREMENT SPECIFICATION 1.Introduction to the Document 1.1 Purpose of the Product 1.2 Scope of the Product 1.3 Acronyms, Abbreviations, Definitions 1.4 References 1.5 Outline of the rest of the SRS 2.General Description of Product 2.1 Context of Product 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 3.Specific Requirements 3.1 External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces 3.2 Functional Requirements Class Class 2 3.3 Performance Requirements 3.4 Design Constraints 3.5 Quality Requirements 3.6 Other Requirements 4.Appendices In validation, we check that our requirements definition accurately reflects the customer's needs In verification, we check that one document or artifact conforms to another Verification ensures that we build the system right, whereas validation ensures that we build the right system VALIDATION AND VERIFICATION LIST OF TECHNIQUES TO VALIDATE REQUIREMENTS Review the stated goals and objectives of the system Compare the requirements with the goals and objectives Review the environment in which the system is to operate Review the information flow and proposed functions Assess and document the risk, discuss and compare alternatives Testing the system: how the requirements will be revalidated as the requirements grow and change REQUIREMENT REVIEWS Check that the requirements-specification document corresponds to the requirements- definition Make sure that if we implement a system that meets the specification, then the system will satisfy the customer's requirements Make sure that each requirement in the definition document is traceable to the specification VERIFICATION Measurements focus on three main areas product process resources Number of requirements can idea of the size of the developed system Number of changes to requirements Many changes shows some uncertainty or instability in our understanding of the system Requirement-size and change measurements should be recorded by requirements type MEASURING REQURIEMENTS 1.You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirement 2.Some elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the past 3.Some elements of this requirement are very different from requirements in the past, but you understand the requirement and can develop a good design from it 4.You cannot understand some parts of this requirement, and are not sure that you can develop a good design for it 5.You do not understand this requirement at all, and can not develop a design for it MEASURING REQUIREMENT READINESS SCALE List of selection Criteria Applicability Implementability Testability/Simulation Checkability Maintainability Modularity Level of abstraction Soundness Verifiability Run time safety Tools maturity Looseness Learning curve Technique maturity Data modelling Discipline Steps Determine which of the criteria are really important Evaluate each of the candidate techniques with respect to the criteria Choose a specification technique that best supports the criteria that are most important to the problem CHOOSING A SPECIFICATION LANGUAGE The model represents a very simple abstraction of persons who study or work at university The class (person) has different subclasses: Every student is a person and had a matriculation number (matN)r and matriculation date (matDate) Every employee is a person and has S.S number (soSecNr) PHD Student is a special employee who had a dissertation subject (diss Subject) EXAMPLE: UML CLASS DIAGRAM The user inserts an ATM card, the ATM requests a PIN, the user enters a PIN; the ATM verifies the PIN with the bank's database. The "processing" message stands for the ATM showing a message saying the PIN is processing. After the bank says the PIN is valid, the ATM presents the transaction choices ("option") and the user selects withdrawal. The ATM then asks for the amount to withdraw. REAL TIME EXAMPLE The Diagram shows users ATM withdrawal transaction Software Engineering: Theory and Practice (Fourth Edition),Shari Lawrence Pfleeger, Joanne M. Atlee Software Engineering-A Practitioners Approach ;Roger S. Pressman SOURCES