Requirement Analysis

Requirement Analysis ... what the customer requires from a software system ... Requirement Analysis

Contents • Provide a justification. • Specify requirements desired properties. • Discuss: • problems • solutions Requirement Analysis

Requirements • It is very difficult to formulate a complete and consistent requirements specification • A requirements definition, a requirements specification and a software specification are ways of specifying software for different types of reader • The requirements document is a description for customers and developers Requirement Analysis

Requirements Errors • Requirements errors are usually very expensive to correct after system delivery • Reviews involving client and contractor staff are used to validate the system requirements • Stable requirements are related to core activities of the customer for the software • Volatile requirements are dependent on the context of use of the system Requirement Analysis

A Requirement ... ? • It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification • This is inevitable as requirements may serve a dual function • May be the basis for a bid for a contract - therefore must be open to interpretation • May be the basis for the contract itself - therefore must be defined in detail • Both these statements may be called requirements Requirement Analysis

IEEE a Requirement Definition • A condition of capability needed by the user to solve a problem or achieve an objective • A condition or capability that must be meet or possessed by a system ... to satisfy a contract, standard, specification, or other formally imposed document Requirement Analysis

Requirement Analysis • For large system is the most difficult and intractable activity • It is an error prone activity • It is probably the software engineering weakest and critical area • Requirements analysis produce among others the Software Requirements Specification (SRS) Requirement Analysis

Requirement Engineering • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed • Requirements may be functional or non-functional • Functional requirements describe system services or functions • Non-functional requirements is a constraint on the system or on the development process Requirement Analysis

Requirements analysis • Sometimes called requirements elicitation or requirements discovery • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints • May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders Requirement Analysis

Why so Difficult? • A project is initiated by clients needs ! • There is no formal document describing the clients needs ! • The document describing clients need is the result of the analysis ! • requirement analyst has to identify the requirements by talking to people ! Requirement Analysis

Large Systems • Most large software systems address difficult problems • Problems which are so complex that they can never be fully understood and where understanding develops during the system development • Therefore, requirements are normally both incomplete and inconsistent Requirement Analysis

Why Inconsistency ? • Large software systems must improve the current situation. It is hard to anticipate the effects that the new system will have on the organization • Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements • System end-users and organizations who pay for the system have different requirements • Prototyping is often required to clarify requirements Requirement Analysis

Requirement Analysis Problems • Stakeholders don’t know what they really want • Stakeholders express requirements in their own terms • Different stakeholders may have conflicting requirements • Organizational and political factors may influence the system requirements • The requirements change during the analysis process. New stakeholders may emerge Requirement Analysis

Requirement Analysis Problems • Clients usually do not understand software or software development processes • Developers do not understand clients’ problem or application area • SRS is a medium through which users and clients needs are specified • A good SRS should satisfy ALL the PARTIES ... which is very hard to achieve ... Requirement Analysis

Activity • Requirements analysis aims to specify what some people have in their minds • The input to this activity is • incomplete • informal • imprecise • and may also inconsistent Requirement Analysis

Product • The output of the requirement analysis is a set of requirements, hopefully: • complete • unambiguous • consistent • Requirements analysis produce the Software Requirements Specification (SRS) Requirement Analysis

SRS The objective of SRS is to specify what is needed from the system not how the system will provide it! ... unfortunately, how at one level my be what at lower level ... SRS must give enough detail to allow developers to actually build and test the system Requirement Analysis

SRS Properties • An SRS establishes the basis for agreement between the client and the supplier on what the software product will do. • An SRS provide reference for validation of final product. • A high-quality SRS is a prerequisite to high quality software. • A high-quality SRS reduce development costs. Requirement Analysis

Errors Cost It had been discovered that in some project 54 % of the errors were detected after unit testing and that 45 % of this errors were actually originated during early stages i.e., 25 % of the error occurs during requirement and early design stages Requirement Analysis

Definition/Specification • Requirements definition • A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers • Requirements specification • A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor • Software specification • A detailed software description which can serve as a basis for a design or implementation. Written for developers Requirement Analysis

Definition/Specification • Requirements definition • Customer-Oriented descriptions of the system’s functions and constraints on its operation • Requirements specification • Precise and detailed descriptions of the system’s functionality and constraints. Intended to communicate what is required to system developers and serve as the basis of a contract for the system development Requirement Analysis

Requirement Reader Client managers System end-users Client engineer Contractor managers System architect Requirements Definition System end-users Client engineers System architect Software developers Requirements Specification Requirement Analysis

Definition Definition • The software must provide a means of representing and accessing • external files created by other tools. Requirement Analysis

Specification Specification 1.1 The user should be provided with facility to define the type of external files. 1.2 Each external files type may have an associated tool which may be applied to the file 1.3 Each external files type may be represented as a specific icon on the user’s display. 1.4 Facilities should be provided for the icon representing an external file type to be defined by the user 1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the external file type to the file represented by the selected icon. Requirement Analysis

Requirement Engineering Process • Feasibility study • Find out if the current user needs be satisfied given the available technology and budget? • Requirements analysis • Find out what system stakeholders require from the system • Requirements definition • Define the requirements in a form understandable to the customer • Requirements specification • Define the requirements in detail Requirement Analysis

Requirement Process Requirements definition and specification Requirement Validation Domain Prioritization Understanding Process Entry Requirement Conflict Collection Resolution Classification Requirement Analysis

Process Activities • Domain understanding • Requirements collection • Classification • Conflict resolution • Prioritization • Requirements validation Requirement Analysis

Analysis Issues • Obtain the needed information ... • may be you are not really welcome ... after all knowledge is power ... • Organize the obtained information ... • a huge amount of unstructured information barely ever let you to check consistency ... Requirement Analysis

Analysis Issues • Resolving contradictions ... • you probably must mediate between conflicting requirements or user needs or ... • Focus on what and avoid to mix requirement and design Requirement Analysis

Analysis Partition • Divide et impera: divide the problem into sub problems • Partition with respect to: • objects • functions Requirement Analysis

Objects/Functions • Objects: • entities in the real world with clear, defined boundaries and independent existence (sensors, bill, managers). • Functions: • a task, service, process or activity that is now performed in the real world and it has to be performed by the system. Requirement Analysis

Analysis Approaches • Informal: • a series of meetings between users/clients and analysts serve to prepare SRS. • Structured: • function or object based decompositions are used while modeling the problem. Requirement Analysis

Requirement Specification • DFD, OO models, use cases focus on problem structure • User interface are not modeled • Error situation, log messages are not modeled • Performance, design and recovery constraints are not specified Requirement Analysis

Methodology • Data Flow Diagram (DFD) • Object Oriented Modeling (OO) • Use cases There are many other methodology e.g., Entity-Relationship (ER) or Structured Analysis and Design Technique (SADT) Requirement Analysis

DFD • DFD is a graph showing how data flow through the system. • A data from an input undergoes, possibly, many transformations before reaching an output. • DFDs capture, represent data transformations. • DFD constituents: • data, processes, input sources, output sinks and arrows to represent the flow Requirement Analysis

DFD Notation Invoice Process A transformer, an activity Pay An external entity Sink or source Worker MyFile External files A repository And operator * A data item or a collection of data item, arrow represents flow direction A Or operator + Notice each edge must have a label !!!! Requirement Analysis

Teller Machine Customers Accounts Balance New balance Update Account Get Check Amount due Positive Balance Account Amount Amount * Withdrawal amount PIN Receipt Issue Money Customer Money Requirement Analysis

DFD Drawing Strategy • Identify major inputs and outputs (ignore errors first!) • Start from input and work towards output identifying major transformations • Or viceversa start from output and ... • Start from high level DFD with few transformation and go into more detailed DFD • Try more than one DFD before settling one Requirement Analysis

Data Dictionary • It is the repository of various data flows • Notation is similar to regular expressions: • + sequence or composition • | selection, or • * one or more occurrences Requirement Analysis

Data Dictionary Example Balance = user name + user account + user id + current balance Withdrawal amount = [50000|100000|150000|200000|250000]+user id New balance = user name + user account + user id + [current balance]* PIN = digit + digit + digit + digit + digit Requirement Analysis

DFD Common Errors • Unlabeled data flow • Missing data flow: information required by a process is not available • Extraneous data flow: some information is not being used in the process • Consistency not maintained during refinement • Missing processes • Contain some control information Requirement Analysis

DFD Structured Methodology • Each system is characterized as a transformation function operating with the environment transforming environment inputs into environment output. • Track the flow of data through the system Requirement Analysis

Methodology Steps • Study the “physical environment”, draw a DFD of the current (may be partially automated) system • Draw the logical equivalents of the DFD for the physical system i.e., change John_office_pay into issue_check • Draw a logical model and DFD for the new system with no separation between processes automated and not • Establish a man machine boundary i.e., specify what will be automated Requirement Analysis

Requirements Document • The requirements document is the official statement of what is required of the system developers • Should include both a definition and a specification of requirements • It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it Requirement Analysis

Requirements Rationale • It is important to provide rationale with requirements • This helps the developer understand the application domain and why the requirement is stated in its current form • Particularly important when requirements have to be changed. The availability of rationale reduces the chances that change will have unexpected effects Requirement Analysis

Requirement Traceability • Requirements traceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source • Traceability is a property of a requirements specification which reflects the ease of finding related requirements • Notice that we must be able to trace requirements into design elements, into code, into test cases ... Requirement Analysis

Traceability Type • Requirements-sources traceability: links the requirement and the people, documents which specified the requirement (e.g., customer, incident report, quality standard, international regulations) • Requirements-rationale traceability: why the requirement has been specified • Requirements-requirements traceability: links a requirement with other requirements, which are in some way dependent on them. Requirement Analysis

Traceability Type Continue • Requirements-architecture traceability: links requirements with sub-systems where these requirements are implemented i.e., who is going to develop what. • Requirements-design traceability: links requirements with specific components in the system which are used to implement them • Requirements-interface traceability: links requirements with interfaces of external systems which are used in the provision of the requirements. Requirement Analysis

Traceability Technique • Assign a unique number to all requirements • Cross-reference related requirements using this unique number • Produce a cross-reference matrix for each requirements document showing related requirements. Several matrices may be necessary for different types of relationship Requirement Analysis

Requirements Document Requirements • Specify external system behavior • Specify implementation constraints • Easy to change • Serve as reference tool for maintenance • Record forethought about the life cycle of the system i.e. predict changes • Characterize responses to unexpected events Requirement Analysis

Requirement Analysis