IT T52: SOFTWARE ENGINEERING

UNIT II System Engineering: Requirements elicitation - Need for SRS - Requirement Process - Problem Analysis Informal Approach - Cardinality and modality Entity / Relationship diagram - Data Flow Modeling Object-Oriented Modeling - Prototyping - Requirements Specification - Characteristics of an SRS Components of an SRS - Specification - Structure of a Requirements Document - Functional Specification with Use Cases - Extensions - Developing Use Cases - Requirements analysis and negotiation - Requirements validation - Requirements management Joint Application Development.

SOFTWARE REQUIREMENTS A requirement can be defined as (1) A condition of capability needed by a user to solve a problem or achieve an objective (2) A condition or a capability that must be met or possessed by a system. Need for SRS The origin of most software systems is in the needs of some clients. The software system itself is created by some developers. Finally, the completed system will be used by the end users. Thus, there are three major parties interested in a new system: the client, the developer, and the users. The problem is that the client usually does not understand software or the software development process, and the developer often does not understand the client's problem and application area. This causes a communication gap between the parties involved in the development project. A basic purpose of SRS is to bridge this communication gap. Advantages of SRS An SRS establishes the basis for agreement between the client and the supplier on what the software product will do An SRS provides a reference for validation of the final product. A high-quahty SRS is a prerequisite to high-quahty software A high quality SRS reduces the development cost.

REQUIREMENT PROCESS

The requirement process is the sequence of activities that need to be performed in the requirements phase and that culminate in producing a high quality document containing the SRS. The requirements process typically consists of three basic tasks: problem or requirement analysis, requirement specification, and requirements validation Problem analysis - The basic purpose of this activity is to obtain a thorough understanding of what the software needs to provide. Requirements specification - It focuses on specifying the requirements in a document. Issues such as representation, specification languages, and tools, are addressed during this activity Requirements validation - focuses on ensuring that what has been specified in the SRS are indeed all the requirements of the software and making sure that the SRS is of good quality.

IT T52: SOFTWARE ENGINEERING

As shown in the figure, from the specification activity we may go back to the analysis activity. This happens as frequently some parts of the problem are analyzed and then specified before other parts are analyzed and specified. In specification focus is on the external behavior of the system. In order to identify all the external behaviors, the structure of the problem and its various components need to be clearly understood besides understanding its inputs and outputs.
PROBLEM ANALYSIS /REQUIREMENT ANALYSIS

The aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, what exactly is desired from the software, and what are the constraints on the solution. The basic principle used is divide and conquer. That is, partition the problem into subproblems and then try to understand each subproblem and its relationship to other subproblems in an effort to understand the total problem. The concepts of state and projection can also be used effectively in the partitioning process. A state of a system represents some conditions about the system. When using state, a system is first viewed as operating in one of the several possible states, and then a detailed analysis is performed for each state. This approach is sometimes used in real-time software or process-control software. In projection, a system is defined from multiple points of view . While using projection, different viewpoints of the system are defined and the system is then analyzed

IT T52: SOFTWARE ENGINEERING

from these different perspectives. The different "projections" obtained are combined to form the analysis for the complete system.

Informal Approach
The informal approach to analysis is one where no defined methodology is used. the information about the system is obtained by interaction with the client, end users, questionnaires, study of existing documents, brainstorming, etc. the analyst will have a series of meetings with the clients and end users. In the early meetings, the clients and end users will explain to the analyst about their work, their environment, and their needs as they perceive them. Any documents describing the work or the organization may be given, along with outputs of the existing methods of performing the tasks. Once the analyst understands the system to some extent, he uses the next few meetings to seek clarifications of the parts he does not understand. In the final few meetings, the analyst essentially explains to the client what he understands the system should do and uses the meetings as a means of verifying if what he proposes the system should do is indeed consistent with the objectives of the clients. An initial draft of the SRS may be used in the final meetings.

Data Flow Modeling

Data-flow based modeling referred to as the structured analysis technique uses functionbased decomposition while modeling the problem. It focuses on the functions performed in the problem domain and the data consumed and produced by these functions. It is a top-down refinement approach, which was originally called structured analysis and specification, and was proposed for producing the specifications. Data Flow Diagrams and Data Dictionary Data flow diagrams (also called data flow graphs) are commonly used during problem analysis. A DFD shows the flow of data through a system. It views a system as a function that transforms the inputs into desired outputs. The DFD aims to capture the transformations that take place within a system to the input data so that eventually the output data is produced. The agent that performs the transformation of data from one state to another is called a process (or a bubble). So, a DFD shows the movement of data through the different transformations or processes in the system. The processes are shown by named circles and data flows are represented by named arrows entering or leaving the bubbles. A rectangle represents a source or sink and is a net originator or consumer of data. A source or a sink is typically outside the main system of study. An example of a DFD for a system that pays workers is shown in below.

IT T52: SOFTWARE ENGINEERING

In this DFD there is one basic input data flow, the weekly timesheet, which originates from the source worker. The basic output is the paycheck, the sink for which is also the worker. In this system, first the employee's record is retrieved, using the employee ID, which is contained in the timesheet. From the employee record, the rate of payment and overtime are obtained. These rates and the regular and overtime hours are used to compute the pay. After the total pay isdetermined, taxes are deducted. To compute the tax deduction, information from the tax-rate file is used. The amount of tax deducted is recorded in the employee and company records. Finally, the paycheck is issued for the net pay. The amount paid is also recorded in company records. All external files such as employee record, company record, and tax rates are shown as a labeled straight line. The need for multiple data flows by a process is represented by a '*' between the data flows. This symbol represents the AND relationship. Similarly, the OR relationship is represented by a ' between the data flows. This DFD is an abstract description of the system for handling payment. A DFD represents the flow of data, while a flowchart shows the flow of control. A DFD does not represent procedural information. To construct a DFD is to start by identifying the major inputs and outputs. Minor inputs and outputs (like error messages) should be ignored at first. Then starting from the inputs, work toward the outputs, identifying the major transforms in the way Following are some suggestions for constructing a data flow graph Work your way consistently from the inputs to the outputs, or vice versa. If you get stuck, reverse direction. Never try to show control logic Label each arrow with proper data elements. Inputs and outputs of each transform should be carefully identified. Make use of * and + operations and show sufficient detail in the data flow graph. Try drawing alternate data flow graphs before settling on one.

IT T52: SOFTWARE ENGINEERING

DFDs can be hierarchically organized, which helps in progressively partitioning and analyzing large systems. Such DFDs together are called a leveled DFD set. A leveled DFD set has a starting DFD, which is a very abstract representation of the system, identifying the major inputs and outputs and the major processes in the system. Then each process is refined and a DFD is drawn for the process. In a DFD, data fiows are identified by unique names. These names are chosen so that they convey some meaning about what the data is. However, the precise structure of data flows is not specified in a DFD Data Dictionary The data dictionary is a repository of various data flows defined in a DFD. The associated data dictionary states precisely the structure of each data fiow in the DFD. Components in the structure of a data fiow may also be specified in the data dictionary, as well as the structure of files shown in the DFD.

The Structured Analysis Method The structured analysis provides methods for organizing and representing information about systems. It also provides guidelines for checking the accuracy of the information. Hence, for understanding and analyzing an existing system, this method provides useful tools.

IT T52: SOFTWARE ENGINEERING

An Example A restaurant owner feels that some amount of automation will help make her business more efficient. She also believes that an automated system might be an added attraction for the customers the following goals for the new system were established: Automate much of the order processing and billing. Automate accounting. Make supply ordering more accurate

With these goals, we can define the boundaries for change in the DFD. It is clear that the new system will affect most aspects of the previous system, with the exception of making dishes. The DFD for the new system is shown below. The major files in the system are: Supplies file, Accounting file. Orders file, and the Menu. The data dictionary for this.

IT T52: SOFTWARE ENGINEERING

Object-Oriented Modeling
In object-oriented modeling, a system is viewed as a set of objects. The objects interact with each other through the services they provide. the goal of modeling is to identify the objects (actually the object classes) that exist in the problem domain, define the classes by specifying what state information they encapsulate and what services they provide, and identify relationships that exist between objects of different classes, such that the overall model is such that it supports the desired user services. Each object has certain attributes, which together define the object. Separation of an object from its attributes is a natural method that we use for understanding systems (a man is separate from his attributes of height, weight, etc. Objects of similar type are grouped together to form an object class. class is essentially a type definition, which defines the state space of objects of its type and the operations. An object also provides some services or operations. These services are the only means by which the state of the object can be modified or viewed from outside. For operating a service, a message is sent to the object for that service. Class diagrams represent a structure of the problem graphically using a precise notation. In a class diagram, a class is represented as a portrait-style rectangle divided into three parts. The top part contains the name of the class. The middle part lists the attributes that objects of this class possess. And the third part lists the services provided by objects of this class. To model relationship between classes, a few structures are used. The generalization-specialization structure can be used by a class to inherit all or some attributes and services of a general class and add more attributes and services. The aggregation structure models the whole-part relationship.

IT T52: SOFTWARE ENGINEERING

Instances of a class may be related to objects of some other class. For example, an object of the class Employer may be related to many objects of the class Employee. This is captured through associations. An association is shown in the class diagram by having a line between the two classes. The multiplicity of an association specifies how many instances of one class may relate to an instances of the other class through this association. An association between two classes can be one-to-one or one-tomany. Multiplicity is specified by having a star (*) on the line adjacent to the class representing zero or more instances of the class may be related to an instance of the other class. The class diagram below has five classes of objects, each with a defined name, some attributes, and services. For example, an object of class Chemist has the attributes Name, Registration number, and Address. It has one service Chemist Sales(), which computes the total sales by this chemist. The DrugStore class is an aggregation of the class Medicine and the class Chemist (representing that a drugstore is composed of medicines and chemists). A Medicine may either be Off-the-shelf or Prescription. The class Medicine has some attributes like Name, Quantity in stock, and Expiry-date, and has services like Expired() (to list the expired medicines), OutOfStock() (to list medicines that are no longer in stock), etc. These attributes and services are inherited by the two specialized classes. In addition to these, the Off-the-shelf class has another attribute qty-on-shelf, representing how many have been put on the shelf and have services related to shelf stock. The Prescription class has Refrigeration-needs and Warnings as specialized attributes and services related to them. There are various associations in this model. Eg: , there is an association between Sale and Medicine. This association is one-to-many, that is, one sale could be of many medicines. Similarly, Drug-Store is associated to Medicine and Chemist, and Chemist is associated with Sale.

IT T52: SOFTWARE ENGINEERING

Prototyping
In prototyping, a partial system is constructed, which is then used by the client, users, and developers to gain a better understanding of the problem and the needs. A software prototype can be defined as a partial implementation of a system whose purpose is to learn something about the problem being solved or the solution approach Advantages: 1. Visualizing the operation of the software that is yet to be built ,makes the user satisfy the ultimate objectives 2. Clients and the users can assess their needs much better if they can see the working of a system There are two approaches to prototyping 1. Throw away prototyping 2. Evolutionary prototyping Throw away prototyping In this approach ,the prototype is constructed with the idea that it will be discarded after the analysis is complete, and the final system will be built from scratch Evolutionary prototyping In this approach, the prototype is built with the idea that it will eventually be converted into the final system. Prototyping can be considered vertical or horizontal based on the different aspects of the system. Horizontal prototyping - In horizontal prototyping the system is viewed as being organized as a series of layers and some layer is the focus of prototyping.

IT T52: SOFTWARE ENGINEERING

Eg : the user interface layer is frequently a good candidate for such prototyping, where most of the user interface is included in the prototype. Vertical prototyping - In vertical prototyping, a chosen part of the system, which is not well understood, is built completely. The cost of developing and running a prototype can be around 10% of the total development cost. However , the requirement errors and volume of requirement change requests are much reduced thereby reducing the cost of development itself. The first step in developing a prototype is to prepare an SRS for the prototype. The SRS need not be formal but should identify the different system utilities to be included in the prototype. REQUIREMENTS SPECIFICATION The final output is the software requirements specification document (SRS). An analyst typically will analyze some parts of the problem and then write the requirements for that part.

Characteristics of an SRS
To properly satisfy the basic goals, an SRS should have certain properties and should contain different types of requirements. A good SRS is 1. Correct 2. Complete 3. Unambiguous 4. Verifiable 5. Consistent 6. Ranked for importance and/or stability 7. Modifiable 8. Traceable Correct - An SRS is correct ,if every requirement included in the SRS represents something required in the final system. Complete - An SRS is complete if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. Unambiguous - An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language, which are inherently ambiguous. Verifiable - An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement. Consistent - An SRS is consistent if there is no requirement that conflicts with another.Terminology can cause inconsistencies. Eg, different requirements may use different terms to refer to the same object. . Ranked for importance and/or stability - All the requirements for software are not of equal importance. Some are critical, others are important but not critical, and there are some which are desirable but not very important. An SRS is ranked for importance and/or stability if for each requirement the importance and the stability of the requirement are indicated. Modifiable - An SRS is modifiable if its structure and style are such that any necessary change can be made easily while preserving completeness and consistency. Traceable - An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development

IT T52: SOFTWARE ENGINEERING

Components of an SRS
The following are some of the system properties that an SRS should specify. Functionality Performance Design constraints imposed on an implementation External interfaces Functional Requirements Functional requirements specify which outputs should be produced from the given inputs. They describe the relationship between the input and output of the system. For each functional requirement, a detailed description of all the data inputs and their source, the units of measure, and the range of valid inputs must be specified. All the operations to be performed on the input data to obtain the output should be specified. This includes specifying the validity checks on the input and output data, parameters affected by the operation, and equations or other logical operations that must be used to transform the inputs into corresponding outputs. An important part of the specification is the system behavior in abnormal situations, like invalid input or error during computation. The functional requirement must clearly state what the system should do if such situations occur.An example of this situation is an airline reservation system, where a reservation cannot be made even for valid passengers if the airplane is fully booked. Performance Requirements This part of an SRS specifies the performance constraints on the software system. All the requirements relating to the performance characteristics of the system must be clearly specified. There are two types of performance requirements: static and dynamic. Static requirements - impose constraint on the execution characteristics of the system. These include requirements like the number of terminals to be supported, the number of simultaneous users to be supported, and the number of files that the system has to process and their sizes. These are also called capacity requirements of the system. Dynamic requirements specify constraints on the execution behavior of the system. These typically include response time and throughput constraints on the system. Response time - the expected time for the completion of an operation under specified circumstances. Throughput - the expected number of operations that can be performed in a unit time. The SRS may specify the number of transactions that must be processed per unit time, or what the response time for a particular command should be. All of these requirements should be stated in measurable terms. DESIGN CONSTRAINTS There are a number of factors in the client's environment that may restrict the choices of a designer. The following factors may have an impact on the design of the system. Standards Compliance: This specifies the requirements for the standards the system must follow. The standards may include the report format and accounting procedures. Hardware Limitations: Hardware limitations can include the type of machines to be used,operating system available on the system, languages supported, and limits on primary and secondary storage. Reliability and Fault Tolerance: Fault tolerance requirements can place a major constraint on how the system is to be designed. Fault tolerance requirements often make the system more complex and expensive.

IT T52: SOFTWARE ENGINEERING

Security: Security requirements place restrictions on the use of certain commands, control access to data, provide different kinds of access requirements for different people, require the use of passwords and cryptography techniques, and maintain a log of activities in the system. External Interface Requirements All the interactions of the software with people, hardware, and other software should be clearly specified. The interface requirement should specify the interface with other software the system will use or that will use the system. This includes the interface with the operating system and other applications. SPECIFICATION LANGUAGE Requirements specification requires the use of some specification language. The language should support the desired qualities of the SRS. The language should be easy to learn and use. If formal languages are to be used, they are often used to specify particular properties or for specific parts of the system. The overall SRS is generally in a natural language, and when feasible and desirable Advantage in using Natural Language - Both client and supplier understand the language STRUCTURE OF A REQUIREMENTS DOCUMENT All the requirements for the system have to be included in a document that is clear and concise. So, the requirements are organized into document as sections and subsections. The general structure of an SRS is given below

The introduction section contains the purpose, scope, overview, etc. of the requirements document. It also contains the references cited in the document and any definitions that are used. Section 2 describes the general factors that affect the product and its requirements. Schematic diagrams showing a general view of different functions and their relationships with each other can often be useful. Section 3 describes all the details that the software developer needs to know for designing and developing the system. The external interface requirements section specifies all the interfaces of the software: to people, other softwares, hardware, and other systems. The performance section should specify both static and dynamic performance requirements. In the functional requirements section, the functional capabilities of the system are described.