REQUIREMENTS ENGINEERING PROCESS Requirements engineering provides the

REQUIREMENTS ENGINEERING PROCESS

Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification and managing the requirements as they are transformed into an operational system. Feasibility Study Feasibility Report Requirements Elicitation & Analysis System Models Requirement Specification User & System Requirements Requirement Validation Requirement Document

The Requirements Engineering process can described in five distinct steps: 1. Feasibility Studies 2. Requirements Elicitation 3. Requirements Analysis and Negotiation 4. Requirements Specification 5. Requirements Validation 6. Requirements Management 1. Feasibility Studies The Requirements engineering process should start with a feasibility study. The input to the feasibility study is an outline description of the system and how it will be used within an organization. a. Does the system contribute to the overall objectives of the organization. b. Can the system be implemented using current technology and within given cost and schedule constraints c. Can the system be integrated with other systems which are already in place?

If a system does not support these objectives, it has no real value to the business. Carrying out a feasibility study involves. a. Information Assessment b. Information Collection c. Report Writing Information Assessment This phase identifies the information which is required to answer the three questions set out above. Once the information have been identified, the information sources has to be questioned to answer the following: a. How would the organization scope if this system was not implemented. b. what are the problems with current process and how would a new system help alleviate (improve) these problems? c. What direct contribution will the system make to the business objectives? d. Can information be transferred to and from other organizational systems? e. Does the system require technology which has not previously been used in the organization? f. What must be supported by the system and what need not be supported?

Requirements Elicitation Problems making requirements elicitation difficult: a. Problem of scope (Unnecessary technical details) b. Problem of understanding (Poor Understanding) c. Problems of Volatility (Change over time) d. Problems of political factors (any influence of political) e. Domain Understanding (To Understanding the specialized area) f. Requirements Collection (System to discover their requirements) g. Classification (Prober organization) h. Conflict Resolution (To resolve the two same user requirements) i. Prioritization (Important requirement to solve first priority) j. Requirements Checking (Validate the user Requirements) k. Requirements Specification (Written documents, Graphical model, and formal mathematical model) l. Requirements Documents ( To prepare the SRS document)

Guidelines for Requirements Elicitation a. Assess the business and technical feasibility for the proposed system. b. Identify the people who will help specify requirements and understand the organizational bias. c. Identify domain constraints d. Define technical environment (Eg. Computing architecture, OS, Telecommunication. e. Define or more requirement elicitation methods such as interviews, focus groups and team meetings. f. Identify ambiguous requirements as candidates for prototyping. g. Identify key requirements. Requirements Analysis & Negotiation a. Is each requirement consistent with the overall objective for the system / product? b. Have all requirements been specified in the proper level of abstraction? c. Is the requirement really necessary? d. Is each requirement bounded and Unambiguous? e. Does each requirement have attribution?

f. Do any requirements conflict with other requirements? g. Is each requirement achievable in the technical environment that will house the system or product? h. Is each requirement testable, once implemented. Requirements Specification a. Requirements Specification means different things to different people. b. A Specification can be a written document, a graphical model, a formal mathematical model, a collection of usage scenarios; a prototype, or any combination of these. c. The System Specification is the final work product produced by the system and requirements engineer. It server as the foundation for hardware engineering, software engineering, database engineering and human engineering. d. The System Specification also describes the information that is input to and output from the system.

Requirements Validation a. Requirements validation is the process of determining than the specification is consistent with the requirements definition. b. Requirements validation examines to ensure that all system requirements have been stated unambiguously, that inconsistences, omissions and errors have been detected and corrected and the work products conform to the standards established for the process and the product. c. During the requirements validation process, different types of checks should be carried our on the requirements in the requirement document. These checks include: i. Validity Checks (Inevitable a compromise across the user community) ii. Consistency Checks (Different description of the same system function) iii. Completeness Checks (Define all functions and constraints intended by the system user) iv. Realism (Practically) Checks (Requirements should be checked to ensure that they can actually be implemented) v. Verifiability (The System requirements should always be written so that they are verifiable.

Requirements Validation Techniques Technologies Manual Techniques Description Reading Manual Cross Referencing Interviews Reviews (Complete, Consistent, Comprehensibility, Traceability) Checklists Manual models to check functions & relationships Scenarios Mathematical proofs Automated Techniques Automated cross referencing Automated models to exact functions Prototypes Verifiability,

Requirements Management a. Requirements management is a set of activities that help the project team to identify, control and track requirements and changes to requirements at any time to the project proceeds. b. Each requirement is assigned a unique identifier that might take the form: Requirement type may be F - Functional Requirement D – Data Requirement B – Behavioral Requirement I – Interface Requirement P – Output Requirement Classes a. Enduring Requirements (Stable Requirements) b. Volatile Requirements (Change during the System development) Mutable Requirement (Changes to the environment) Emergent Requirement (Customer understanding of the system develops) Consequential Requirement ( Change the organizations process) Compatibility Requirements (Business processes within an organization)

Requirements Management Planning a. Requirements Identification (Uniquely Identified) b. Change Management Process (Assesses the impact and cost of changes) c. Traceability Policies (Overall property of a requirements specification) i. Source traceability information (Links the requirements to the customers or Stockholder who proposed the requirements) ii. Requirement Traceability information (links dependent requirements written the requirement document) iii. Design Traceability information (links the requirement to the design modules where these requirements are implemented) d. Case Tool Support (Requirement management involves the processing of large amounts of information about the requirements (eg. ) spread sheets and database. ) i. Requirement Storage (Requirements should be maintained in a secure, managed data store) ii. Change Management (Requirements change management should be applied to all proposed changes to the requirement.

e. Problem analysis and change specification i. Change analysis and costing (The effect of the proposal change is assessed using traceability information) ii. Change Implementation (The requirement document the system design and implementation is modified) SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT The Software Requirement Specification (SRS) document is procedure at the combination of the analysis task. It is the official statement of what is required of the system developers A number of different large organizations such as Do. D (Department of Defence) and IEEE have defined standards for requirement document. The most widely known standard is IEEE / ANSI 830 – 1993 standard. The IEEE standard suggest the following standard:

1. Introduction 1. 1 Purpose of the requirements document 1. 2 Scope of the products 1. 3 Definitions, Acronyms and Abbreviations 1. 4 References 1. 5 Overview of the remainder of the document 2. General Description 2. 1 Product perspective 2. 2 Product Functions 2. 3 User Characteristics 2. 4 General Constraints 2. 5 Assumptions and Dependencies 3. Specific Requirements: 4. Appendices 5. Bibliography and Index

Users of Software Requirement Document System Customers Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements Managers Use the requirements document to plan a bid for the system and to plan system development process. System Engineers Use the requirements to understand what system is to be developed System test Engineers Use the requirement to develop validation tests for the system System Maintenance Engineers Use the requirements to help understand the system and the relationship between its parts

Characteristics of an SRS A good SRS should be 1. Correct - If every requirement represents something required in the final system. 2. Complete - Ensures everything (ie) every requirement is indeed specified. 3. Unambiguous - Every requirement stated how one any only interpretation 4. Verifiable - If an only if every stated requirement verifiable. 5. Consistent - No Requirement conflicts with another 6. Ranked for importance and / or stability 7. Modifiable - SRS is well structure so easily change the requirement. 8. Traceable - All requirements are clear and facilitates referencing of other in future development

Components of an SRS The basic issues all SRS must address are 1. Functionality 2. Performance 3. Design constraints imposed on an implementation 4. External Interface Specification Languages Notations Description Standard English Natural languages are widely used for specifying requirements but sometimes it may be imprecise and ambiguous. Regular Expression Used to specify the structure of symbol strings formally. Used in compiler construction for recognition of symbols and tokens. Decision table Provide a mechanism for specifying complex decision logic Finite state Automata An FSA can be specified pictorially formally as grammar and translation rules or transition tables, used for specifying communication protocols.

Bad SRS Document Content Descriptions Noise Presence of text containing information irrelevant to the problem. Silence aspects important to proper solution of the problem are omitted Over specification restricts the solution space for the designer. Contradictions if the same thing described at several places in different ways. Ambiguity Literary expressions Forward References to aspects of problem Wishful Thinking for which realistic solutions will be hard to find.

CLASSICAL ANALYSIS

Petri Net Introduction A Petri net (also known as a place / transition net or P / T net) is one of several mathematical modeling languages for the decryption of distributed System. A Petri net is a directed bipartite graph, in which the nodes represent transitions (i. e. events that may occur, signified by bars) and places (i. e. conditions, signified by circles). The directed arcs describe which places are pre – and / or post conditions for which transitions (signified by arrows). It was first introduced by Carl Adam Petri in 1962. It is a diagrammatic tool to model concurrency and synchronization in distributed systems.

Petri Nets • A major difficulty with specifying real – time systems is timing v Synchronization problems v Race condition v Deadlock • Often a consequences of poor specification. • Petri nets A powerful techniques for specifying systems that have potential with interrelations • A Petri ne consists of four parts: v A set of places P v A set of transitions T v An input function I v An output function O • Set of places P is {p 1, p 2, p 3, p 4} • Set of transitions T is {t 1, t 2}

• Input function: v I(t 1) = {P 2, P 4} v I(t 2) = {P 2} • Output function v O(t 1) = {P 1} v O(t 2) = {P 3, P 3} • More formally, a Petri net is a 4 – tuple C = (P, T, I, O) v P = {P 1, P 2, P 3, . . Pn} is a finite set of places, n >= 0 v T = {t 1, t 2, t 3, . . tn} is a finite set of transaction, m >= 0 with P and T disjoint v I: T -> P is the Input function, a mapping from transitions to bags of places. v O: T -> P is the Output function, a mapping from transitions to bags of places. P 2 t 2 P 1 t 1 P 3 P 4

• A marking of a Petri net is an assignment of tokens to that Petri net. . . P 1 . P 2 t 1 P 3 . P 4 • Four tokens: one in P 1, two in P 2, none in P 3, and one in P 4 v Represented by the vector (1, 2, 0, 1) v A transition is enabled if each of its input places has as many tokens in it as there arcs from the place to that transition. • Transition t 1 is enabled (ready to fire) v If t 1 fires one token is removed from P 2, and one from P 4, and one new token is places in P 1 v Transition t 2 is also enabled

• Important v The number of tokens in not conserved • Petri nets are indeterminate v Suppose t 1 fires v The resulting marking is (2, 1, 0, 0) . P 1 . . P 2 t 1 P 3 P 4 • Now only t 2 is enabled v It fires t 2

P 2 P 1 . . t 1 t 2 . . P 3 P 4 • The marking is now (2, 0, 2, 0) • More formally, a marking M of a Petri net C = (P, T, I, O) is a function from the set of places P to the non – negative integers P 2 M : P -> {0, 1, 2, ……} • A marked Petri net is then a 5 – tuple (P, T, I, O, M) P 1 t 1 • Inhibitor arcs v An inhibitor arc is marked by a small circle, not an arrowhead • Transition t 1 is enabled P 3 . • In general, a transition is enabled if there is at least one token on each (normal) input are, and no tokens on any inhibitor input arcs.

Petri Nets: The Elevator Problem Case Study • A Product is to be installed to control n elevators in a building with m floors • Each floor is represented by a place, Ff, 1<= f <= m • An elevator is represented by a token • A token in Ff denotes than an elevator is at floor Ff. First constraint 1. Each elevator has a set of m buttons, one for each floor. These illuminate where pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the corresponding floor is visited by an elevator. v The elevator button for floor f is represented by place EBf, 1<= f <= m v A token in EBf denotes that the elevator button for floor f is illuminated v A button must be illuminated the first time the button is pressed and subsequent button presses must be ignored • If button EBf is not illuminated, no token is in place and transition EBf pressed is enabled. v The transition fires, a new token is placed in EB

EBf pressed Elevator in action EBf Ff . Fg . • Now, no matter how many times the button is pressed, transition EBf pressed cannot be enabled • Wen the elevator reaches floor g v A token is in place Fg v Transition Elevator in action is enabed, and then fires • The tokens in EBf and Fg are removed v This turns off the light in button Ebf • A new token appears in F v This brings the elevator from floor g to floor f

• Motion from floor g to floor f cannot take place instantaneously v We need timed petri nets Second constraints 2. Each floor, except the first and the top floor, has two button, one to request an up elevator, one to request a down elevator, These buttons illuminate when pressed. The illumination is canceled when the elevator visits the floor, and then moves in desired direction. • Floor button are represented by places FBuf and FBdf • The Petri net in the previous slide models the situation when an elevator reaches floor Fj from floor Fg with one or both buttons illuminated. • If both buttons are illuminated, only on e turned off. • A more complex model is needed to ensure that the correct light is turned off.

EBf pressed Elevator in action EBuf . . EBf pressed Ff Fg Ff EBdf . Elevator in action

Third Constraints 3. If an elevator has no requests, it remains at its current floor with its doors closed. • If there are not requests, no Elevator in action transition is enabled. • Petri nets can also be used for design • Petri nets posses the expressive power necessary for specifying synchronization aspects of real – time system.

Data Dictionary The data dictionary is an organized testing of all data elements that are relevant to the system so that both the user and system analyst will have a common understanding inputs, outputs, components of stores and intermediate calculations. It is proposed as quasiformat grammar during structured analysis and may contain the following information: A data Dictionary is simplistically an alphabetic list of names which are included in different models of the system. Field Name Description Name of the data item. Aliases Other name of the data item. Description / Purpose A notation for representing its goal or context. Related data item Relevant data item. Range of value Value between the item. Data Structure Definition Form of the data item Where used / How used Input to the process, output from the process, as a store and external entity Supplementary information Data types, preset values, restrictions or limitations.

Example Field Name Description Name Telephone_Number Aliases Phone_Number, Mobile_Number Description / Purpose First 2 digit indicates Country Code, Next 4 digits represents district code, Last 6 digit indicates your number, etc. Where used / How used Address / Visiting Card / Display / read the Telephone_Number Format Numeric / Min 6 digit / max 10 digit / Starts with +, etc. . Data Dictionary Notation

The mathematical operation used in data dictionary is defined as follows: Sl. No. Notation Meaning 1. X=a+b X consists of data elements a & b. 2. X = [a / b] X consists of either data elements a or b. 3. X=a X consists of an optional data element a. 4. X = Y{a} X consists of Y or more occurrence of data element a. 5. X = {a}z X consists of Z or fever occurrences of data element a 6. X = y {a} z X consist of some occurrence of data element a which are between Y and Z. Advantages 1. Mechanism for name management. The data dictionary software can check for name uniqueness and tell requirements analysts of name duplications. The names should be used consisting and should not clash. 2. It serves as a store of organizational information that can link analysis, design, implementation and evaluation. 3. The data dictionary software might be integrated with other tools so that dictionary creation is partially automated. 4. Design the software and test cases.