UNIT II

SOFTWARE REQUIREMENTS
IEEE defines Requirement as : 1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or a system component to satisfy constract,standard,specification or formally imposed document 3. A documented representation of a condition or capability as in 1 or 2

Encompasses both the Users view of the requirements( the external view ) and the Developers view( inside characteristics) Users Requirements are Statements in a natural language plus diagram, describing the services the system is expected to provide and the constraints. System Requirements describe the systems function, services and operational condition.

Functional and Non_Functional requirements:

Definition:Functional requirements are statement of the services that the system should provide or are descriptions of how the system should react to particular inputs and how the system should behave in particular situation. In some cases ,the functional requirements may also explicitly state what the system should not do,for a system describe what the system should do. These requirements depend on the type of software being developed,expected users of the software and the type of system where the software is used. Functional user requirements may be high level statements of what the system should do best functional system requirements should describe the services in detail. e.g.LIBSYS system is a single interface provided to multiple databases,collection of articles from different libraries .A user to download copies of articles. Functional requirements for a University library system used by students and staff. 1.user shall be able to search either all of the initial set of databases or select a subset from it. 2.System shall provide appropriate viewers for the user to read document store. 3.Every order shall be allocated a unique identifier(ORDER_ID) which user shall be able to copy to the accounts permanent storage area. Problem Associated with requirements: Requirements specification imprecision:
38

1.Problems arise for software engineering .When requirements are not precisely stated. 2.Ambiguous requirement may be interperet by a system developer to simplify its implementation.On account of customer needs ,new requirements have to be established and change made to the system due to this delay in system delivery and increase costs. Appropriate Viewers: User intention:It does not make clear that viewers for each document format should be provided. Developer:Provide a text viewer and that the requirement to be met that the content of the document. Principle: The functional requirements specification of a system should be both complete and consistent. Completeness:It means that all services required by the user should be defined. Consistencey:It means that requirements should not have contradictory definition or no conflicts in the descriptions of the system facilities. Actually in practice ,it is impossible to achieve requirements consistency and completeness for large and complex systems. Nonfunctional requirements: Definition:Non-functional requirements constraints the system being developed and the development process that should be used .They may be product requirements,organizational requirements or external requirements.They often relate to the emergent properties of the system and therefore apply to the system as whole. The Non-functional requirement define system properties and constraints. Requirements are not directly concered with the specific functions delivered by the system. It consists of various properties of a system can be:Reliability,response time,storage requirements and constraints of the system can be input and output devices capability system representations and the data representations used in system interfaces. Process requirements may also specify programming language or development method. Non-fuctional requirements are more critical than functional requirements.If the Nonfunctional requirements do not meet then the complete sytem is of no use. Rarely associated with individual system features rather these requirements specify system performance security,availability and other developing properties. Classification of non-functional requirements:

39

The non-functional requirements derived from required charecteristics of the software(product requirements),the organization developing the software (organizational requirements) or from external sources.

The types of non-functional requirements are: 1.Product requirements : These requirements specify product behavior(e.g)performance requirements on how fast the system must execute and how much memory it requires;reliability requirements that set out the acceptable failure rate :portability requirements and usability requirements . 2.Organisational requirements: Derived from policies and procedures in the customers and developers organization. (e.g) implementation requirements the programming language or design method used. Delivery requirements that specify when the product and its documentation are to be delivered. 3.External requirements : Covers all requirements that are derived from factors external to the system and its development process.

SOFTWARE PROTOTYPING:
Rapid software development to validate requirements Objectives To describe the use of prototypes in different types of development project To discuss evolutionary and throw-away prototyping
40

 To introduce three rapid prototyping techniques high-level language development. Database programming and component reuse To explain the need for user interface prototyping. System prototyping: Prototyping is the rapid development of a system The principal use is to help customers and developers understand the requirements for the system
o

Requirements elicitation- Users can experiment with a prototype to see how the system supports their work

o Requirements validation The prototype can reveal errors and omissions in the requirements.

Prototyping can be considered as a risk reduction activity

Prototyping benefits: o Misunderstandings between software users and developers are exposed. o Missing sevices may be detected and confusing services may be identified o A working system is available early in the process o The prototyping may serve as a basis for deriving a system specification o The system can support user training and system testing.

Prototyping in the software process:

Approaches to prototyping:

Evolutionary prototyping An initial prototype is produced and refined through a number of stages to the final system. Throw-away prototyping A prototyping is produced to help discover requirements problems and then discarded. The system is then developed using some other development process. Approaches to prototyping:
Evolutionary Out line Requirements prototyping 41 Delivered system

Throw-way prototyping

Executable prototype+system specification

Prototyping objectives:

The objective of evolutionary prototyping is to deliver a working system to end-users

o

The development starts with those reauirements which are best understood.

The objective of throw-away rptotyping is to validate or derive the system requirements o The prototyping process startrs with those requirements which are poorly understood.

Evolutionary prototyping: Must be used for systems where the specification cannot be developed in advance e.g.AI system and user interfsce systems. Based on techniques which allow rapid system iterations. Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system.

Develop abstract specification

Build prototype system

Use prototype system

Deliver system

System Adequa te?

Evolutionary prototyping advantages: Accelerated delivery of the system Rapid delivery and deployment are sometimes more important than functionality or longterm software maintainability.
42

User engagement with the system Rapid prototyping techniques: Various techniques may used for rapid development -Dynamic high level language development -Database programming -Component and application assembly These techniques are often used together,Visual programming is an inherent part of most prototype development systems Dynamic high level languages which include powerful data management facilities and need a large run time support system.not normally used for large system development.Some languages offer excellent UI development facilities and have an integrated support environment whose facilities may be used in the prototype.

THE SOFTWARE REQUIREMENTS DOCUMENT

The software requirements document called SRS is the official statement of what the system developers should implement.It should include both the user requirements for a system and a detailed specification of the system requirements,In some cases the user and system requirements may be integrated into single description.User requirements defined in an introductionto the system requirement specification. Heninger suggests that there are 6 requirements that requirement document should satisfy. It
should

specify only external system behavior specify constraints on the implementation. Be easy to change Serve as reference tool for system maintainers Record forethought about the life cycle of the system. Characterize acceptable responses to undesired events Purpose of SRS

communication between the Customer, Analyst,system developers, maintainers, firm foundation for the design phase support system testing activities Support project management and control,controlling the evolution of the system IEE standard suggests the following structure for requirements documents

1.Introduction
43

1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview 2. General description 2.1 Product perspective 2.2 Product function summary 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3. Specific Requirements cover functional ,non-functinal and interface requirements.This is obviously most substantial part of the document but because of the wide variability in organizational practice is not appropriate to define in standard structure.The requirement may be document external interfaces,system functionality and performance,specify logical database requirements,design constraints,emergent sytem properties and quality characteristics - Functional requirements -External interface requirements - Performance requirements - Design constraints - Attributes eg. security, availability,maintainability, - Other requirements 4.Appendices 5.Index transferability/conversion

REQUIREMENTS ENGINEERING PROCESS

Definition of Requirement Engineering :Process of findingout,analysising,documenting and checking these services and constraints is called requirement engineering(RE).
44

Requirement themselves are the descriptions of the system services and constraints that are generated during the requirement engineering process.

The goal of requirement engineering process to create and maintain a system requirement document The overall process includes four high level requirements engineering sub-processes: 1.Feasibility study:Concerned with assessing whether the business 2.Elicitation and analysis :Discovering requirements 3.Specifications:Converting the requirements into a standard form 4.Validation: Checking that the requirements actually define the system that the customer wants system is useful to the

The requirements engineering process

Feasibility study Requir ements elicitation and anal ysis

Requir ements specification Requir ements validation

F easibility repor t System models User and system requirements

Requir ements document

Spiral Representation Of Requirements Engineering Process Process represented as three stage activity Activities are organized as an iterative process around a spiral. Early in the process, most effort will be spent on understanding high-level business and the user requirement. Later in the outer rings, more effort will be devoted to system requirements engineering and system modeling Three level process consists of: 1.Requirements elicitation 2. Requirements specification
45

3. Requirements validation

FEASIBILITY STUDIES Starting point of the requirements engineering process Input: Set of preliminary business requirements, an outine description of the system and how the system is intended to support business processes Output: Feasibility report that recommends whether or not it is worth carrying out further Feasibility report answers a number of questions: 1.Does the system contribute to the overall objective 2.Can the system be implemented using the current technology and within given cost and schedule 3.Can the system be integrated with other system which are already in place. . Requirements elicitation and analysis
After performing Feasibility study the requirements elicitation and analysis can be done. Requirements elicitation means discovery of all possible requirements. After identifying all possible requirements the analysis on these requirements can be done; Software engineers communicate the end-user or customers in order to find out certain information such as: application domain, expected services from the system, the expected performance level of the system. From this information even constraints of the can be decided. The commonly used term Stakeholder refers to any person or group who will affected by the system directly or indirectly i.e. end users, engineers, business managers, domain experts. 46

Eliciting and understanding stakeholder requirements is difficult for several reasons: 1.Stakeholders often dont know what they want from the computer systemand and may find it difficult to communicative what they want the system to do because they are unaware of the cost of their requests. 2.Stakeholders expression of requirements in natural language is sometimes difficult to understand by requirements engineering,must understand requirements. 3.Different stakeholders express requirements differently .Requirement engineers have to consider all possible sources of requirements and discover commonalities and conflict. 4.Political factors may influence the requirements of the system Example managers may demand specific system requirements that will increase their influence in the organization. 5.Change in requirements due to dynamic environment during the analysis process. The Requirements elicitation and analysis process

Each organization will have its own version of this general model,depending on local factors such as the expertise of the staff,the type of system being developed and the standards used. These activites within a spiral are interleaved as the process proceeds from the inner to the outer rings of the spiral. It is an iterative process with continual feedback from each activity to other activities. The process cycle starts with requirements discovery and ends with requirements documentation . The analysts understanding of the requirements improves with each round of the cycle.
47

The process activities are: 1.Requirement Discovery: Interacting with stakeholder in the system to collect their requirements including domain requirements from stakeholders and documentation are also discovered. 2.Requirements classification and organisation : This activity takes the unstructured collection of requirements,groups related requirements and organizes them into coherent(logical) clusters. 3. Requirements prioritization and negotiation:

Multiple stakeholders have different views or requirements will conflict.This process is assigning priority to requirements. Resolves conflicting requirements through negotiation. It is impossible to completely satisfy every stakeholder,but if some feel that their views have not properly considered ,deliberately(knowingly)try to undermine the RE process.

4.Requirements documentation:

Requirements be documented and input placed in the next round of spiral. Formal or informal an early version of the system requirements document may be produced. But it will have missing sections and incomplete requirements , otherwise easy for stakeholders to handle,change and organise the requirements may be documented as tables in a document or on cards. Writing requirements on cards very effective.

Requirements Discovery Techniques: View points Viewpoint-oriented approaches to requirements engineering organise both the elicitation process and the requirements themselves using view points. Viewpoint oriented analysis is that it recognizes multiple perspectives and provides a framework for discovering conflicts in the requirements proposed by different stakeholders. Viewpoints can be used as a way of classifying stakeholders and other sources of requirements. Three Generic types of viewpoints 1.Interactor viewpoints Represents people or other system that interact directly with the system
48

2.Indirect viewpoints Stakeholders who influence the requirements, but dont use the system 3.Domain viewpoints Requirements domain characteristics and constraints that influence the requirements. Interviewing --Puts questions to stakeholders about the system system to be developed. --Requirements are derived from the answers Two types of interview Closed interviews where the stakeholders answer a pre-defined set of questions. Open interviews discuss a range of issues with the stakeholders for better understanding their needs. that they use and the

Effective interviewers a) Open-minded: no pre-conceived ideas b) Prompter: prompt the interviewee to start discussion with a question or a proposal LIBSYS scenario

Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing the copy of the article. Normal: The user selects the article to be copied. He or she is then prompted by the system to either provide subscriber information for the journal or to indicate how they will pay for the article. Alternative payment methods are by credit card or by quoting an organisational account number. The user is then asked to fill in a copyright form that maintains details of the transaction and they then submit this to the LIBSYS system. The copyright form is checked and, if OK, the PDF version of the article is downloaded to the LIBSYS working area on the users computer and the user is informed that it is available. The user is asked to select a printer and a copy of the article is printed What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form should be re-presented to the user for correction. If the resubmitted form is still incorrect then the users request for the article is rejected. The payment may be rejected by the system. The users request for the article is rejected. The article download may fail. Retry until successful or the user terminates the session.. Other activities: Simultaneous downloads of other articles.
49

System state on completion: User is logged on. The downloaded article has been deleted from LIBSYS workspace if it has been flagged as print-only.

Use cases Use cases are the fundamental units of modelling language, in which functionalities are distinctly presented. The use case is a scenario based technique.Its help to identify individual interactions with the system. Its are extensively used for requirements elicitation. By designing theproper use cases for different scenarios major requirements of the system can be identified. The typical notations used in the use cases are.

L S Su ec s s IB Y s a e
A t le er h r ic s ac

L rr i ay b Ue sr

A ic pi t g rt l rnin e

Ue a m isr to s r d in tai n

L rr ibay Saf tf

Sp l r up ie

Ct l g e ev e aa u s r i s o c

Flow of events can be described as System start up : The system is started when the operator turns on the switch. Initially the operator has to enter some amount of money int the cash dispenser. The connection with the bank gets established. Then only the servicing customer can begin. System shutdown : The operator can shoutdown the system only after confirming that there is no customer currently operating the ATM system. Then the connection to the bank gets disconnected. Session : This use case starts when the user inserts the card. ATM pulls the card inside and reads it. Then further inquiry information is displayed on the display panel. Transaction : The transaction use case is comprised of amount withdrawal, deposit and inquiry.

50

Ethnography : Ethnography means is a comparative study of people. The software systems exit for social or organizational purpose. That means the ethnography is a technique of obtaining the social and organizational requirements. Ethnography is useful for finding following type of requirements. 1.Requirements obtained from working style of people These are requirements that can be identified from the sequence of actions that a user is performing. For example in ATM system when the user enters the PIN, the card validity action takes place. Unless and until the card gets validated there should not be any transaction processing. That means, it is required that a valid card, valid PIN must be entered for getting the money from ATM. 2. Requirements obtained from inter-activities performed by the people Sometimes for finding the social requirements the other peoples activities should be known. For example in ATM system the operator can not shutdown the system if some transaction is in processing. REQUIREMENTS VALIDATION Concerned with showing that the requirements define the system that the customer wants. Important because errors in requirements can lead to extensive rework cost Validation checks 1.Validity checks --Verification that the system performs the intended function by the 2.Consistency check
51

--Requirements should not conflict 3. Completeness checks --Includes requirements which define all functions and system user 4. Realism checks --Ensures that the requirements can be actually implemented 5. Verifiability -- Testable to avoid disputes between customer and developer REQUIREMENTS MANAGEMENT Requirements are likely to change for large software systems and as such requirements management process is required to handle changes. Reasons for requirements changes (a) Diverse Users community where users have different requirements and priorities (b) System customers and end users are different (c) Change in the business and technical environment after installation Enduring and volatile requirements Requirements evolution during the RE process and after a system gone into service is inevitable. Developing software requirements focuses attention on software capabilities ,business objectives and other business systems. constraints intended by the

Requirements evolution
Initial understanding of problem Changed understanding of prob lem

Initial requirements

Changed requirements Time

Two classes of requirements (a) Enduring requirements: Relatively stable requirements (b) Volatile requirements: Likely to change during system
52

Requirements management planning

An essential first stage in requirement management process is planning The requirements management stage have to decide on the following 1.Requirements identification -- Each requirement must have unique tag for cross reference and traceability 2.Change management process -- Set of activities that assess the impact and cost of changes 3.Traceability policy -- A matrix showing links between requirements and other elements of software development 4.CASE tool support --Automatic tool to improve efficiency of change management process. Automated tools are required for requirements storage, change management and traceability management Maintains three types of traceability information: Traceability is the property of a requirements specification that reflects the ease of findings related requirements 1.Source traceability --Links the requirements to the stakeholders 2. Requirements traceability --Links dependent requirements within the requirements document 3. Design traceability -- Links from the requirements to the design module

A traceability matrix

53

Traceability matrix that records the dependencies between requirements and may be used when a small number of requirements have to be managed ,but they become unwidely and expensive to maintain for large systems with many requirements. A D in the row /column intersection that the requirement in the row depend on the requirement named in the column An R mens someother ,weaker relationship between the requirements (e.g) Both D and R define the requirements for the part of the same subsystem. Requirements Change Management Revised requiremen ts Identified problem
Problem analysis andchange specification Change analysis and coding Change implemen tation

Consists of three principal stages: 1. Problem analysis and change specification -- Process starts with a specific change proposal and analysed to verify that it valid 2.Change analysis and costing --Impact analysis in terms of cost, time and risks 3. Change implementation --Carrying out the changes in requirements document, system design and its implementation is

SYSTEM MODELS
Used in analysis process to develop understanding of the existing system that is to be replaced orimproved or to specify the new system. Develop different models to represent the system from different perspectives: 1.An external perspective ,where the context or environment of the system is modeled. 2.A behavioural perspective,where the behavior of the system is modeled 3. A Structural Perspective ,where the architecture of the system or the structure of the data processed by the system is modelled
54

Types of system models 1.Context models 2. Behavioural models 3.Data models 4.Object models 5.Structured models

Context Models
A type of architectural model Consists of sub-systems that make up an entire system First step: To identify the subsystem Represent the high level architectural model as simple block diagram Depict each sub system a named rectangle Lines between rectangles indicate associations between subsystems Disadvantages --Concerned with system environment only, doesn't take into account other systems, which may take data or give data to the model The context of an ATM system:

It is an architectural model define the structure of the information system that include a bank ATM (auto-teller network). Consist of sub-system is represented by named rectangle and lines indicate association between sub-system. Each ATM is connected to an account database,a local branch accounting system,a security system and a system to support machine maintenance and monitor the network of ATMs.The counter system provides backup and printing services.
55

Behavioural models

Describe the overall behaviour of athesystem. Two types of behavioural model 1.Data Flow models:which model the data processing in the system 2.State machine models:which model how the system reacts to events Data flow models --Concentrate on the flow of data and functional transformation on that data --Show the processing of data and its flow through a sequence of processing steps --Help analyst understand what is going on Advantages -- Simple and easily understandable -- Useful during analysis of requirements

Insulin pump DFD

Blood parameters Blood sugar sensor Blood sugar analysis Blood sugar level Insulin requirement computation Insulin Pump control commands Insulin pump Insulin delivery controller Insulin requirement

Blood

It represent esch transformation a single function or process,during the analysis of requirement s as they can used to show end-to-end processing in a system.ie the entire sequence of actions that take place from an input being processed to the corresponding output .

State machine models

Describe how a system responds to internal or external events Shows system states and events that cause transition from one state to another Does not show the flow of data within the system Used for modeling of real time systems Example:Microwave oven
56

Microwave oven m odel

Full pow er Full po wer do: set power = 600 Timer Waiting do: display time N umber Full power H alf power Set time do: get number exit: set time Door closed Door open H alf po wer do: set power = 3 00 Enabled Door closed do: display 'R eady' Operation do: operate oven

Half po wer

Timer

Cancel Start D oor open Waiting do: display time

Disa led b do: display 'Waiting'

Assumes that at any time, the system is in one of a number of possible states Stimulus triggers a transition from on state to another state Disadvantage -- Number of possible states increases rapidly for large system models

DATA MODELS

Used to describe the logical structure of data processed by the system. An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes Widely used in database design. Can readily be implemented using relational databases. No specific notation provided in the UML but objects and associations can be used.

57

Library semantic model

A r t ic le t itle a u th o rs p df f il e fe e 1 d e live r s n O rd e r o r de r n u m b e r t o t a l p a ym e n t d a te t ax s ta t u s n p la c e s 1 B uy e r n am e a d dre s s e - m a il b illin g in f o C o p y r ig ht A g e nc y 1 n am e haa s- linskss d dr e in 1 1 m t itle p ub lis h e r f e e - pa y a b le - to 1 is su e d a te p a ge s 1 in 1 C o u nt r y c o py righ t f o rm t ax r a t e p ub lis h e d- in n S o ur c e

An important part of systems modeling is defining the logical form of the data processed by the system called sementic data models. LIBSYS is library system designed to deliver copies of copy righted articles .Therefore the data model must include information about the article ,the copyright holder and the buyer of the article through national copyright agencies not specified payment for article directly. DATA DICTIONARY: A data dictionaries are useful when developing system models and used to mange all information from all types of system models The dictionary should include an associated description of the named entity and if the name represents a composite object ,a description of the composition,other information date of creation the representation of the entity also included depending the type of model Examples of data dictionary entries:

Data dictionary entries

58

The advantages of using a data dictionary are: 1.It is a mechanism for name management :Developing a large system model many people may have to invent names for entities and relationships .The name should be consistenly and not clash,data dictionary check for name uniqueness 2.It serves as a store of organizational information:as the system developed that can link analysis ,design implementation and evolution is added to the data dictionary,so all information in one place.

Object Models

An object oriented approach is commonly used for interactive systems development Expresses the systems requirements using objects and developing the system in an object oriented PL such as c++ A object class: AN abstraction over a set of objects that identifies common attributes Objects are instances of object class Many objects may be created from a single class Analysis process -- Identifies objects and object classes Object class in UML --Represented as a vertically oriented rectangle with three sections (a) The name of the object class in the top section (b) The class attributes in the middle section (c) The operations associated with the object class are in lower section.

Inheritance Models

A type of object oriented model which involves in object classes attributes Arranges classes into an inheritance hierarchy with the most general object class at the top of hierarchy Specialized objects inherit their attributes and services UML notation -- Inheritance is shown upward rather than downward --Single Inheritance: Every object class inherits its attributes and operations from a single parent class --Multiple Inheritance: A class of several of several parents.

59

Hierarchy of class
Library item Ca talogue number Acquisition da te Cost T ype Sta tus Number of copies Acquir () e Ca talogue () Dispose () Issue () R eturn ()

Published item Title Publisher

Recor ded item Title Medium

Book Author Edition Publica tion date ISBN

Magazine Y ear Issue

Film Director Date of release Distributor

Computer program Version Platform

Object Aggregation
-- Some objects are grouping of other objects -- An aggregate of a set of other objects -- The classes representing these objects may be modeled using an object aggregation model -- A diamond shape on the source of the link represents the composition

Object-Behavioral Model
-- Shows the operations provided by the objects -- Sequence diagram of UML can be used for behavioral modeling

Object aggregation
Study pack Course title Number Year Instructor

Assignment Credits

OHP slides Slides

Lecture notes T ext

Videotape T ape ids.

Exercises #Problems Description

Solutions T ext Diagrams

60

Acquiring attributes through an inheritance relationship with other objects,some objects are grouping of other objects ie an objects is an aggregate of a set of other objects.The class represent these object may be modeled using an object aggregation model The UML notation for aggregation is to represent the composition by including a diamond shape on the source of the link.

Object behavior modelling

The behavior of objects ,to show how the operations provided by the objects are used . To model behavior is to use UML sequence diagrams that show the sequence of actions involved in a use-case as well as sequence diagrams,The UML includes collaboration diagrams that show the sequence of messages exchanged by objects .Explaination of diagram: In sequence diagram,objects and actors are aligned along the top of the diagram. Labeled arrows indicate operations,the sequence of operation is from top to bottom.

OBJECT BEHAVIORAL MODEL

Ecat: Catalog :Library Item Lib1: NetServer :Library User

Lookup Display Issue Issue licence Accept licence Compress

Deliver

In this scenario,the library user accesses the catalogue to see whether the item required is available electronically,if it is the user requests the electronic issue of that item.For copyright reasons,this must be licensed there is action between the item and the user where the license is agreed.The item to be issused is then sent to anet work server object for compression before being sent to the library user.

61