UNIT 2 REQUIREMENT ENGINEERING The requirements have 7 functions Inception Elicitation Elaboration Negotiation Specification Validation Management Software

oftware Requirement Specification: It has 3 sections 1. Introductory section 2. General description 3. Specific requirement-technical information 3a. Fundamental requirement 3b. External interface requirement 3c. Performance requirement 3d. Design constraints 3e. Attributes System level and software level differ in operating system. Requirement Engineering: The process of establishing the services of the system should provide the constraints under which it must operate is called requirement engineering. It is classified into two types 1. Functional Engineering 2. Non-functional Engineering The requirement may be a functional requirement that is; it describes the system services or functions. Non-functional requirements is a constraints placed on the development process.

Three terms in Requirement Engineering: 1. Requirement Definition 2. Requirement Specification 3. System Specification Requirement Definition: It is a statement in a natural language and diagram of what services; the system is expected to provide constraints under which it must operate. It is generated using customer supplies information. Requirement Specification: It is structured document which sets out the system services in detail. This document is also called as functional specification. So it serves as a contract between system buyer and system developer. System Specification: It is an abstract description of system which is a basis for design and implementation. This specification may add further details to the requirement specification. Example: Requirement definition 1 The system must provide a means of representing and accessing external files created by other tools. Requirement Specification: 1.1> The user should be provided with facility to define the type of external files. 1.2> Each external file type may have an associated tool which may be applied to the file. 1.3> Each external file type may be represented as specific icon on the user display. 1.4> Facility should be for icon representation. 1.5> When a user selects an icon representing an external file, the effect of the selection is to apply the tool associated with the type of external file represented by selected icon.

Drawbacks of requirement gathering: Large systems are usually required to improve up on the status Quo. The existing system may be manual or out of date computer system. Although difficulties with current system may be known, caught to anticipate what effect that the improved system will have on the organization. Large systems usually have a diverse user community. Different users have different requirements; these may be complicating or contradictory. The people who pay the system and the user of the system are rarely the same people. System customers impose requirements because of organization of budgetary constraints. These may conflict end-user requirements. Readers for different types of specification:
Requirement definition Client manager system and users client engg contract manager system architect System end user client engineer system architect software developer Client engineer system architect software developer

Requirement specification

Software specification

Requirement Engineering Process: These are four principle stages in this process. Feasibility study- estimate is made of whether the identified user needs may be satisfied with current system and hardware technology. Requirement analysis- the process of deriving the system requirement through observation of existing system.

Requirement Engineering Process

Feasibility study

Requirement analysis

Software models Feasibility report Requirement document

Requirement definition

Requirement specification

Definition of requirement

Specification of requirement

Requirement definition- activity of translating the information gathered during the analysis activity into a document that defines set of requirement. Requirement specification- detailed and precise description of system requirements is set out to act as a basis for a contract between the clients of the system developer. System requirement documents- a system requirement documents sometimes called System Requirement Specification (SRS). It is the official statement of what is required of the system developer. Six requirements which a system requirement documents should satisfy. It should satisfy constraints on the implementation. It should be easy to change. It should serve as a reference tool for the system maintenance. It should record the things about the life cycle of the system. It should categorized acceptable response to undeserved events. Requirement validation- This is concerned with showing the requirements actually defines system that the customer wants validity for several aspects of requirements which has to be checked. 1. Consistency 2. Completeness 3. Realism

Requirement Review: It is a manual process that involves multiple readers from both clients and contractors checking the requirement document for anomalies. Requirement reviews can be formal or informal. Informal Review: Simply involves contractors discussing with clients. Formal Review: The development team should walk or walk-through review the client through system requirement explaining the implication of each requirement. The review team member should check each requirement for consistence should check the requirements a whole for completeness. They might check for verify ability. 1. Traceability: It is the origin of the requirement clearly stated or not. 2. Comprehensibility: Is requirement properly understood by the end-user? 3. Adaptability: Is requirement adaptable. Automated Consistency Checking of Requirements:
Requirement in a formal answer Requirement problem report

Requirement processor

Requirement analyse

Requirement database

Requirement evolution: From an evolution perspective, requirement falls into two classes, and are Enduring requirement Volatile requirement Enduring requirement: These are relatively stable requirement which derive from the core activity of the organization which relate directly to the domain of the system. Example: Hospital management system. Requirements doctors, patients, treatment etc, Volatile requirement: These are the requirements which are likely to change during the system development or after the system have been put into operation. Classification of Volatile requirement: Mutable Requirement Emergent Requirement Consequential Requirement Compatibility Requirement Mutable requirement: Requirements that change because of changes to the environment in which the organization is operating. Example: Funding of patient care may change. Emergent requirement: Requirements that emerge as customers understanding of systems develops during the system development. Consequential requirement: Requirements, that results from the introduction of computer system. Introducing the system may change the organization process and open up new ways of working which generates new system requirements.

Compatibility requirement: The requirements depend on the particular system or business process within an organization. As these change the compatibility requirements on the commissioned or the delivered system may also have to evolve.

Requirement analysis:

System engineer

Software requirem ent analysis

Softwar e design

It is a software engineering task that bridges the gap between system level engineering and software design. So it is divided into five areas. They are; Problem recognition Evaluation synthesis Modeling Specification Software project plan Requirement Elicitation for software: Before the requirements can be analyzed modeled are specified they must be gathered through the elicitation process. Initiating the process: The most commonly used requirement elicitation process is to conduct a meeting or interviews. The first meeting between a software engineering and customer can be made first. The analyst starts by asking context free questions. A set of questions that will lead to a basic understanding of problem among people who want solution, the nature of the solution that is, the desired and effectiveness of the solution. Example: i. Who is behind the request of this work? ii. Who will use the solution?

iii. What will be the economic benefit of successful solution? Facilitated Application Specifications Technique (FAST): The number of investigators has a team oriented approach to requirement gathering that is applied during early stages of analysis and specification is called as Facilitated Application Specification Technique (FAST). This approach encourages a creation of joint team of customers and developers who work together to identify the problem, propose the elements of solution etc. Basic guidelines for Facilitated Application Specifications Technique (FAST): A meeting is conducted at a neutral site and is attended by both software engineers and customers. The rules for preparation and participation are established. Agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas. A facilitator controls the meeting (can be a customer developer or outside person). A definition mechanism is used (can be work sheet or a flip chart or wall stickers or electronic bulletin board or virtual forum is used). The goals is to identify the problem propose the elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements. To better understand the flow of events as they occur in a typical Facilitated Application Specification Technique (FAST) meeting. Quality function development (QFD): It is a quality management technique that translates the needs of the customers into a technical requirement for software. It is classified into three types; Normal Requirements: The objective and goals that are stated for a product or a system during meeting with the customer. If these requirements are present then customer is satisfied. Example: Graphics display, specific system function.

 Expected Requirements: These requirements are implicit to the product or the system and may be so fundamental that the customer does not explicitly state them. Example: Human/machine interactions, overall operations and correctness and reliability. Exiting Requirements: These features go beyond the customers expectations and prove to be very satisfying when present. QFD uses customers interviews, observations, survey and examination of historical data. Usecases: As requirements are gathered as a part of informal meetings FAST/QFD can create set of scenarios that identify a thread of wage for the system to be constructed. These scenarios are called Usecase. To create a usecase must first identify the different types of people. These actors actually represent that people play as system operator. Once the actors can be identified the usecases can be developed. The usecase describes the manner in which the actor interacts with system. Software Prototyping: Rapid software development to validate requirements. Animating and demonstrating system requirements. Uses of System Prototypes: The principal use is to help customers and developers to understand the requirements for the system. Requirement Elicitation: Users can experiment with a prototype to see how the system supports their work. Requirement Validation: The prototype can reveal errors and omission in the requirements. The prototype may be used for the user training before a final system is delivered. The prototype may be used for back to back testing.

 Prototyping can be considered as a risk reduction activity which reduces requirement risks. Prototyping benefits: Misunderstanding between software and developers are exposed. Missing services may be detected. Confusing services may be identified. A working system is available early in the process. The prototype may serve as a basis for deriving a system specification.

System prototyping: Prototyping is the rapid development of system. In the past, the developed system was normally thought of as inferior in some way to the required system and hence further development was required. Now the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach.

Prototyping in the software process: Evolutionary prototyping: An approach for system development where an initial prototype is produced and refined through a number of stages to obtain the final system. Throw away prototyping: A prototype which is usually a practical implementation of the system is produced to discover requirement problems and then it is discarded. The system is then developed using some other development process.

Approaches to Prototyping:
Evolutionary prototyping Delivered system

Outline requirements

Throw away prototyping

Executable prototype system specification

Evolutionary prototyping:

Develop abstract specification

Build prototype system

Use prototype system

Deliver system

System adequate

Evolutionary prototyping: Specification, implementation and design are inter-twined. The system is developed as a series of increment that are delivered to the customer.

 Techniques for rapid system development are used such as CASE tools and four generation languages. User interfaces are usually developed using GUI development toolkit. Advantages: Accelerated delivery of the system. User engagement with the system Evolutionary Prototyping problems: Management Problems Existing management process assumes a waterfall model of development. Specialist skills are required which may not be available in all development teams. Maintenance Problems: Continual change tends to corrupt system structure so long term maintenance is expressive contractual problems. Prototypes or specifications Some parts of the requirements (eg: safety critical functions) may be impossible to prototype and so do not appear in the specification. An implementation has no legal standing as a contact. Non functional requirements cannot be adequately tested in a system prototype. Incremental development: System is developed and delivered in increments after establishing an overall architecture. Requirements and specification for each increment may be developed. Users may experiment with delivered increments while others are being developed. Therefore, these serve as a form of prototype system. Intended to combine some of the advantage of prototyping but a more manageable process and better system.

Incremental developmental process:

Define system deliverables

Design system architectures

Specify system increment

Build system increment

Validate increment

Deliver final system

System Complete

Validate system

Integrate increment

Throw away prototyping: Used to reduce requirements risk. The prototype is developed from an initial specification, delivered for experiment then discarded. The throw away prototype should not be considered as a final system. Some system characteristics may have been left out. There is no specification for long term maintenance. The system will be poorly structured and it is not efficient for the customer satisfaction.

Throw away prototyping

Outline requirement

Develop prototype

Evaluate prototype

Specify system

Develop software

Validate system

Delivered software system

Prototype delivery: Developers may be pressured to deliver throw away prototype as a final system. It may be impossible to tune the prototype to meet non-functional requirements. The system structure will be degraded through changes mode during development. Normal organizational quality standards may not have been applied. Rapid prototyping technique: Various techniques may be used for rapid development. Dynamic high-level language development. Database programming. Component and application assembly. These are not exclusive techniques they are often used together. Visual programming is an inherit part or most prototype development systems.

Advantages: Concrete baseline for communication between users and developers. Allows user to take it for a spin Encourages early user participation and involvement. Allows early observation of user performance. Dangers: Prototype can be overworked (reason for prototype is forgotten) Prototyping tool may influence design. Possibilities of over promising with prototype. Component and application assembly: Prototypes can be creating quickly from a set of reusable components plus some mechanism to glue these components together. The composition mechanism must include control facilities and a mechanism for component communication. The system specification must take into account the availability and functionality of existing components. Prototyping with reuse Application level development. Entire application systems are integrated with the prototype so that their functionality can be shared. For example, if text preparation is required, a standard word processor can be used. Component level development. Individual components are integrated within a standard framework to implement the system. Frame work can be a scripting language or an integration framework such as CORBA CORBA- component object request brokerage architecture. Visual programming: Scripting languages such as visual basic support visual programming where the prototype is developed by creating a user interface from standard items and associations components with these items. A large library of components exist too support this type of development.

User interface prototyping: It is impossible to pre-specify the look and feel of a user interface in an effective way. UI development consumes an increasing part overall system development costs. User interface generators may be used to draw the interface and stimulate its functionalities with components associated with interface entities. Web interface may be prototyped using a web site editor. Key points: A prototype can be used to give end users a concrete impression of the system and capabilities. Prototype is becoming increasingly used for system development where rapid development is essential. Throw away prototyping is used to understand the system requirements. In evolutionary prototyping, the system is developed by evolving an initial version to the final version. Prototyping objectives: The objective of evolutionary prototyping is to deliver a working system to end users. The development starts with those requirements which are best understood. The objective of throw- away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements are understood. User interface prototyping: Prototyping may use very high level languages such as small talk, Java, Visual Basic or Lisp. Prototyping language: LANGUAGE Small talk L GLS CASE tools

TYPE object oriented data base Graphical

APPLICATION DOMAIN interactive system Business DP Business DP

Four generation languages:

Database query language Screen generator Spread sheet Report generator

Database Management System

Steps to successful prototyping Clearly define the purposewhy? What are the approximations? Determine the form of the prototype Determine cost, construction plan. Test gathers data. Key points: Rapid development of prototype is essential. This may require leaving out functionality or relaxing non- functional constraint. Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified. Users must be involved in prototype evaluation. Achievement through prototyping: Improved system durability. Closer match to the system needed. Improved design quality. Improve and maintainability. Reduced overall development effort.

Analysis modeling: Abstract descriptions of system whose requirements are being analyzed. Concrete model Behavioral model Data model System modeling: System modeling helps the analyst to undertake the functionality or the system and models are used to communicate with customers. Different models present the system from different perspectives. External perspective showing system context of the environment. Behavioral perspective showing the behavior of the system. Structure perspective showing the system or data architecture. Method weakness: They do not model non- functional system requirements. They do not usually include information about whether a method is appropriate for a given problem. They may produce much documentation. The system models are sometimes too detailed and difficult for users to understand. Context models: Context models are used to illustrate the boundaries of a system. Social and organizational concerns may affect the decision on where to position system boundaries. Architectural models show the system and its relationship with other systems. Process models show that the overall process and the process that are supported by the system. Data flow models may be used to show the process and the flow of information from one process to another. Presenting system with data flow diagrams: Data flow diagrams are a hardware representation of a system. They are the corner stone for the structured system analysis and design. The diagrams use four symbols to represent any system at any level of detail. The four entities that must be represented are:

Data flows- movement of data in the system Data stores- data repositories for data that is not moving. Process- transforms of incoming data flows and outgoing data flows. External entities sources or destinations outside the specified system boundary. DFD purpose: The purpose of data flow diagrams is to provide a semantic bridge between users and systems developers. The diagrams are: Graphical eliminations thousands of words: Logical representations, modeling what a system does rather than physical models showing how it does the work. . Analysis model: Data modeling: Data modeling methods make use of the entity relationship diagram (ERD) which enables a software engineer to identify the data objects and their relationship. The data model consists of three inter-related pieces of information. 1. Data object 2. Attribute 3. Relationship Data object: A data object can be an external entity (anything that produces or consumes information) a thing, an occurrence or an event or a role an organization unit, a place or a structure. Example: employee data object Attributes o Employee name o Id o Age o Salary o Designation Attributes: Attributes define the properties of the objects. Example: employee name employee id Relationship:

The relationship is the connection between data objects. Example: consider two data objects an employer employee

and

Employer

Employee

Relationship is employee works for employer. The objects or relationship pairs are bidirectional. Cardinality: Cardinality is a specification of the number of occurrences of one object that can be related to the other object. One to one (1:1): An occurrence of an object a can relate to only one occurrence of object b and vice versa. Example: husband-wife One to many (1: n): One occurrence of a object A is related to many occurrence of object B. Example: a parent can have many children but children can have only one parent.
Parent Children

Many to many: Many occurrence of a object A is related to many occurrence of object B.

Example: department-students

Department

Students

Modality: The modality of relationship is zero if there is no explicit need for relationship to occur or the relationship is optional. The value is 1 if the occurrence of relationship is mandatory.
Customer repair

When a customer requests for a repair action which is not necessary then it can be termed as optional.

E-R diagrams: Entity relationship diagram represents how entities are related to each other. The components of ER diagram are 1. Data object 2. Attributes 3. Relationship 4. Various indicators

E-R
Manufacturer

diagram

for
Desi gn

Manufacturing
Ship

ship

Suppl y

Trans port

Shipment

Behavior model: The behavior model indicates how the software will respond to external events or stimuli. To create the model the analyst must perform the following steps: 1. Evaluate all the usecases; fully understand the sequence of interaction within the system. 2. Identify events that derive the interaction, sequence and understand how the events relate to specific classes. 3. Create a sequence for each use case. 4. Build state diagram for the system. 5. Review the behavioral model to verify the accuracy and consistency.

UML diagrams: The unified modeling language (UML) is a standard language for specifying, visualizing, constructing, documentation, business modeling.
Some part of the model might not be visible on any diagram

Sequence diagram

Use case diagram

Class diagram Collaboration diagram Model Activity diagram Component diagram State chart diagram Deployment diagram Object diagram

. Use case diagrams: Overview of usage requirements Presentation for project stakeholders The meet of the actual requirements. Actor: An actor is a person, organization or external system that plays a role in one or more interactions with your system. Use case: A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal eclipse.

System boundary: It indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not.

Class diagram: Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation and association), and the operations and the attributes of the classes.
Order Data received is prepaid number price Dispatch () Close () Customer Name Address Credit rating

Corporate customer Contact name Credit rating Credit limit Permitted bill on month()

Personal customer Credit card

Relationships between class diagrams: Association: An association represent a relationship that specify that object of one thing are connected to objects of another

Association

Person

Company

Aggregation: An association in which one class represents a larger thing which consists of smaller things is called aggregation relation. It is a has a relationship meaning of an object of the whole has object of the past.

Aggregation
Company Whole

Department

Part

Generalization: A generalization is a relationship between a general thing (a super class) and a more specific kind of that thing (a sub class). It is a is a kind of relationship Generalization
Shape Super class

Square

Sub class

get

Dependencies: A dependency is using relationship that states that a change in specification of one thing may affect another thing that uses it. You will use dependencies in the context of classes to show that one class uses another class as an agreement in its method signature. Dependencies
Course schedule Course

+add(c:course) void +remove(c:course) void

Sequence diagram Captures dynamic behavior (time-oriented) Built during analysis and design Purpose Model flow of control Illustrate typical scenarios Developed by analysts, designers and implementers

Collaboration diagram Captures dynamic behavior (message-oriented) Built during analysis and design Purpose o Model flow of control o Illustrate coordination of object structure and control Developed by analysts, designers and implementers

Functional model: The information is transformed as it flows through a computer based system. The system accepts input in varieties of forms i.e. applying hardware, software and human elements to transform input into output. This is called flow model. The flow model can be created for any computer based system regardless of size and complexity. The functional model describes the computation that take place within a system. The final model of a system specifies how the output values are computed in the system from input values without considering the control aspects of computation. When the transformation form input to output is complex consisting of many steps, the functional model is likely to be used.

 The functional model of a system can be represented by DFD. Data flow diagram

External entity

Transfo rm #1 Transf orm #3

External entity

Transf orm #9

External entity

Transf orm #2

Data store

External entity

DFD/Data flow graph/Bubble chart: The data flow graph is a graphical representation that depicts information flow and transforms that are applied as a data moves from input to output. A level of 0 DFD also called a fundamental system model or quantized model represents the entire quantized element or single bubble with input and output. Data indicated by incoming and outgoing arrows. Each of bubbles may be refined at layers to depict more details.

Information flow requirement: The fundamental model for a system (f) describes the primary input as A and ultimate output as B. The F model is refined and transforms into till f5 or function. But the information floe continuity must be maintained i.e. that input or output of each refinement is same. This is called balancing.

Data flow graph/Bubble chart

F1

F2 F 5

F0 F3 F4