Embed Size (px)
Citation preview
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 User’s view of the requirements( the external view ) and the Developer’s view( inside characteristics)
• User’s 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 system’s 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 input’s 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 Non-functional 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
40
To discuss evolutionary and throw-away prototyping
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:
41Delivered system
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.
Evolutionary prototyping advantages:
Accelerated delivery of the system
42
Out line
Requirements
Evolutionary
prototyping
Throw-way prototyping
Executable prototype+system specification
Develop abstract specification
Build prototype system
Use prototype system
Deliver system System
Adequate?
Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability.
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
43
IEE standard suggests the following structure for requirements documents
• 1.Introduction
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, transferability/conversion
- Other requirements
4.Appendices
5.Index
44
REQUIREMENTS ENGINEERING PROCESS
Definition of Requirement Engineering :Process of findingout,analysising,documenting and checking these services and constraints is called requirement engineering(RE).
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 system is useful to 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
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.
45
• 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
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
46
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.
Eliciting and understanding stakeholder requirements is difficult for several reasons:
1.Stakeholders often don’t 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.
47
• 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 analyst’s understanding of the requirements improves with each round of the cycle.
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.
48
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
2.Indirect viewpoints
Stakeholders who influence the requirements, but don’t use the system
3.Domain viewpoints
Requirements domain characteristics and constraints that influence the requirements.
Interviewing
--Puts questions to stakeholders about the system that they use and the 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.
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 user’s computer and the user is
49
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 user’s request for the article is rejected.
• The payment may be rejected by the system. The user’s 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.
• 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.
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.
50
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.
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 people’s 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
51
1.Validity checks
--Verification that the system performs the intended function by the
2.Consistency check
--Requirements should not conflict
3. Completeness checks
--Includes requirements which define all functions and constraints intended by the 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.
52
Two classes of requirements
(a) Enduring requirements: Relatively stable requirements
(b) Volatile requirements: Likely to change during system
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
53
--Links dependent requirements within the requirements document
3. Design traceability
-- Links from the requirements to the design module
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 requirements
Identified problem
Consists of three principal stages:
1. Problem analysis and change specification
-- Process starts with a specific change proposal and analysed to verify that it is valid
2.Change analysis and costing
--Impact analysis in terms of cost, time and risks54
Problem analysis andchange specification
Change analysis and coding
Change implementation
3. Change implementation
--Carrying out the changes in requirements document, system design and its implementation
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
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:
55
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.
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
56
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
• Assumes that at any time, the system is in one of a number of possible states
57
• 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.
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
58
Examples of data dictionary entries:
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
59
• (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.
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 Model60
-- Shows the operations provided by the objects
-- Sequence diagram of UML can be used for behavioral modeling
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.
61
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.
62
