1. CEN 4020 Software Engineering PPT4: REQUIREMENT ANALYSIS Dishant Patel

2.  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?

3.  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

4.  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

5.  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

6.  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

7.  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 don’t understand each other REQUIREMENT ELICITATION

8. HOW USERS AND DEVELOPERS VIEW EACH OTHER

9.  If Users and Developers don’t 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 don’t come up to an agreement than the project is doomed to fail REQUIREMENT ELICITATION

10.  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

11.  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

12.  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

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

14.  Correct  Consistent  Unambiguous  Complete  Feasible  Relevant  Testable  Traceable CHARACTERISTIC OF REQUIREMENT

15.  It’s 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

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

17.  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

18. Message Sequence Chart MODELING NOTATIONS

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

20. MODELING NOTATIONS UML Statechart Diagram

21.  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

22. Use Cases MODELING NOTATIONS Library use cases including borrowing a book, returning a borrowed book, and paying a library fine

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

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

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

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

27. Object Constrain Language  Both mathematically precise and easy for non-mathematicians to read, write, and understand MODELING NOTATIONS

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

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

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

31. 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 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces  3.2 Functional Requirements 3.2.1 Class 1 3.2.2 Class 2 …  3.3 Performance Requirements  3.4 Design Constraints  3.5 Quality Requirements  3.6 Other Requirements 4.Appendices

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

33. LIST OF TECHNIQUES TO VALIDATE REQUIREMENTS

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

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

36.  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

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

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

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

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

41.  http://www.ics.uci.edu/~alspaugh/cls/shr/msc.html http://www.ics.uci.edu/~alspaugh/cls/shr/msc.html  Software Engineering: Theory and Practice (Fourth Edition),Shari Lawrence Pfleeger, Joanne M. Atlee  Software Engineering-A Practitioner’s Approach ） ;Roger S. Pressman  http://code.google.com/p/advancedsoftwareengineering/ SOURCES