Page 1
Paul Dunne GMIT
Software Engineering: Requirements, Analysis and Design
Paul Dunne GMIT
Lecture Outline
uRequirements Engineeringu Intro to Analysis and DesignvDefining Analysis and DesignvWhy do Analysis and Design?vTypes of Analysis and Design
Page 2
Paul Dunne GMIT
Roadmap
Paul Dunne GMIT
Requirements Engineering
u Challenge facing system and software engineers:“How can we ensure that we have specified a
system that:vProperly meets the customer’s needsvSatisfies the customer’s expectations
u Requirements engineering provides mechanisms for:vUnderstanding what the customer wantsv analysing needv assessing feasibilityv negotiating a reasonable solutionv specifying the solutionv validating the specificationvmanaging the transformation of the requirements into an
operational system
Page 3
Paul Dunne GMIT
Requirements Engineering
u The requirements engineering process can be described in six steps:vRequirements elicitationvRequirements analysis and negotiationvRequirements specificationvSystem modellingvRequirements validationvRequirements management
uWe will discuss some of these in more detail
Paul Dunne GMIT
Find-out Analyse Document CheckingThe process of finding, analysing, documenting and checking services and constraints
What is Requirements Engineering?
RAn Abstract description of Services or Constraints for System
Detailed formal mathematical definition of a system function
A range of definitions depending who’s talking!What is a Requirement?
Manager
Coder
Definitions please...
Page 4
Paul Dunne GMIT
So where do all these different requirement definitions come from? Abstraction (Davis)
“If a company wishes to let a contract for a large software development project, it must define its needs in asufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several
contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs.Once a contract has been awarded, the contractor must write a system definition for the client in more detail sothat the client understands and can validate what the software will do. Both of these documents may be called
the requirements document for the system.”
abstractAllow a lot of
people bidAward
Contract
Nailit
down
Requirements Detailed System Requirements
Abstract User Requirements
Paul Dunne GMIT
Say that again ....What is a requirement?
u It may range from v a high-level abstract description of a service or of a system
constraintv to a detailed mathematical functional specification
u This is inevitable as requirements may serve a dual functionv May be the basis for a bid for a contract - therefore must be
open to interpretationv May be the basis for the contract itself - therefore must be
defined in detail
u Both these statements may be called requirements
Page 5
Paul Dunne GMIT
Importance of ‘correct’ Requirements
Paul Dunne GMIT
Requirements Elicitation
u It might seem that this should be simple:vAsk the customer, users, and others:
» What the objectives for the system are» What is to be accomplished» How the system fits the into the needs of the business» How the system will be used on a day-to-day basis
u In fact it is hard!vProblems of scopevProblems of understandingvProblems of volatility
Page 6
Paul Dunne GMIT
Why its Difficult
Paul Dunne GMIT
Problems of Scope
u The boundary of the system may be ill-definedvWho is going to interact with the system?vWhat other systems are involved?vExactly what functionality is the responsibility of the system
» e.g. should a rostering system produce a telephone directory?
u The customer/user may specify unnecessary technical detail that may confuse overall system objectivesve.g. specifying OS, language, hardware, etc. for no particularly
good reason
Page 7
Paul Dunne GMIT
Problems of Understanding /1
uCustomers/users may:vNot be completely sure of what is needed, e.g.:
» “See what you can do to help us”(Marketing director of textile business)
» “Try to improve the project”(Director of British Aircraft Corporation, with reference to theConcorde project)
vHave a poor understanding of the capabilities and limitations oftheir computing equipmentvNot have a full understanding of the problem domainvHave trouble communicating needs to system engineervOmit information believed to be “obvious”vSpecify requirements that conflict with needs of othersvSpecify requirements that are ambiguous or untestable
Paul Dunne GMIT
Problems of Understanding /2
Page 8
Paul Dunne GMIT
Problems of Volatility
uRequirements change over timeuChange is inevitable in most systems, due to
factors such as:vChanges in customer organization, e.g.
» new divisions, new productsvChanges in scale, e.g.
» Number of transactions per day» Number of users» Increased connection bandwidth
vExternal changes» Changes in law (e.g. taxation)» Changes in international standards (e.g. MPEG)
vCustomers get new ideas as they become aware of system possibilities
Paul Dunne GMIT
Overcoming Requirements Elicitation Problems
uSommerville and Sawyer give guidelines for addressing these problemsvAssess business and technical feasibility for the proposed systemv Identify the people who will help to specify requirements, and
understand their organizational biasvDefine the technical environment in which the system will be
placed:» Computing architecture, operating system,
telecommunications needsv Identify “domain constraints” that limit system functionality or
performance» Characteristics of business environment specific to application
domain
Page 9
Paul Dunne GMIT
Overcoming Requirements Elicitation Problems (cont.)
uDefine one or more requirements elicitation methodsv Interviews, focus groups, team meetings
uEnsure that many people participate so that requirements are defined from different points of viewv Identify and record the rationale for each requirement
u Identify ambiguous requirements as candidates for prototypingvA means of addressing volatility
uCreate usage scenarios to help customers/users better identify key requirements
Paul Dunne GMIT
Products of Requirements Elicitation Process
u The requirements elicitation process will produce work products to be included in the software configurationv statement of need and feasibilityv bounded statement of scope for the systemv list of customers, users and other stakeholders who participated
in requirements elicitationv description of system’s technical environmentv list of requirements and their domain constraints
» preferably organized by function v set of usage scenarios (under different operating conditions)v any prototypes that were developed
u All work products are reviewed by participants in requirements elicitation
Page 10
Paul Dunne GMIT
Requirements Analysis and Negotiation
u The products of requirements elicitation form the basis for requirements analysis
uRequirements analysisvCategorises requirements
» Organises them into related sub-setsvExplores relationships between requirementsvExamines requirements for
» Consistency» Omissions» Ambiguity
vPrioritises requirements based on customer/user needs» May lead to plan for incremental development
Paul Dunne GMIT
Requirements Analysis Questions
u Is each requirement consistent with the overall objective for the system?
u Have all requirements been specified at the proper level of abstraction?v i.e. not too much technical detail, or exclusion of future
possibilities
u Is each requirement really necessary?vOr is it an add-on not needed for core system objective?
u Is each requirement bounded an unambiguous?u Does each requirement have an attribution?
vWho or what is the source of the requirement?
u Are there any conflicting requirements?u Is each requirement technically achievable in specified
environment?u Is each requirement testable once implemented?
Page 11
Paul Dunne GMIT
Requirements Negotiation
u It is common for customers/users to ask for more than can be achieved
u Also common for different stakeholders to proposed conflicting requirementsv e.g. cost requirement from management vs. performance
requirement from usersvEach party might argue that their requirement is “essential”
u Requirements engineer must resolve these conflicts through negotiation:vPrioritise requirements, discuss conflicts in this orderv Identify risks associated with requirementsvProduce “guesstimates” of development effort for each
requirement
u In an iterative process, modify, combine or eliminate requirements so that each stakeholder gets some satisfaction
Paul Dunne GMIT
Requirements Management
uWe have noted that changes in requirements:v are essentially unavoidablevwill persist throughout the lifetime of the system
uRequirements management helps the project team to identify, track and control requirements and changes to themvThis is closely related to configuration management
u Traceability tables are developed for requirements
Page 12
Paul Dunne GMIT
Requirement flavours
u Requirements can be considered to come in two, or three, flavours depending on your perspective.
v Functional requirements v Non-Functional requirements v Domain requirements
Paul Dunne GMIT
Functional and non-functional requirements(an artificial distinction?)
u Functional requirements v Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in particular situations.
v FR1: The system should read my id card, then request and read my account password and tell me my account balance.
u Non-functional requirementsv Constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process, standards, etc.
v NFR1: ID cards should be authenticated within 30ms
u Domain requirementsv Requirements that come from the application domain of the system
and that reflect characteristics of that domainv The ATM should be weatherproof (IP65)
Page 13
Paul Dunne GMIT
Functional requirements
uDescribe functionality or system servicesuDepend on the type of software, expected users and
the type of system where the software is usedu Functional user requirements may be high-level
statements of what the system should do .... but ... u Functional system requirements should describe the
system services in detail
What services does the system provide?
Paul Dunne GMIT
Requirements imprecision
u Problems arise when requirements are not precisely stated - in fact its one of software’s biggest problems!
u Ambiguous requirements may be interpreted in different ways by developers and users
u Consider the term ‘appropriate viewers’v User intention -
» Special purpose viewer for each different document typev Developer interpretation
» Provide a text viewer that shows the contents of the document
What I mean
What you think I mean
Page 14
Paul Dunne GMIT
Requirements completeness and consistency
u In principle requirements should be both complete and consistentv Complete
» They should include descriptions of all facilities required
v Consistent
» There should be no conflicts or contradictions in the descriptions of the system facilities
u In practice, it is impossible to produce a complete and consistent requirements document!
Paul Dunne GMIT
Non-functional requirements
u They mayv Define (emergent) system properties
» e.g. reliability, response time and storage requirements. v and constraints
» Constraints are I/O device capability, system representations, etc.
u Process requirements may also be specified:v use a particular CASE system v use a programming language v use Type A development methodv conform to a quality standard.
u Non-functional requirements may be more criticalthan functional requirements. If these are not met, the system is useless
Page 15
Paul Dunne GMIT
Possible metrics for specifying non- functional system properties
Property MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
Paul Dunne GMIT
Domain requirements
uDerived from the application domain of the system rather than the specific needs of system user.
uDescribe system characteristics and features that reflect the domain.
uMay be new functional requirements, constraints on existing requirements or define specific computations
u If domain requirements are not satisfied, the system may be unworkable
Page 16
Paul Dunne GMIT
Domain requirements problems
uUnderstandabilityvRequirements are expressed in the language of the application
domainvThis is often not understood by software engineers developing the
system
u ImplicitnessvDomain specialists understand the area so well that they do not
think of making the domain requirements explicit
Paul Dunne GMIT
Requirements and design
u In principle, requirements should state what the system should do and the design should describe how it does this
u In practice, requirements and design are inseparablev A system architecture may be designed to structure the
requirementsv The system may inter-operate with other systems that
generate design requirementsv The use of a specific design may be a domain requirement
Page 17
Paul Dunne GMIT
Roadmap
Paul Dunne GMIT
Analysis and Design
Page 18
Paul Dunne GMIT
Definitions
uMany different definitions of the difference between analysis and design
u In the past there was common agreementuWas viewed as follows:
EssentialModel
ImplementationModel
Role of the Analyst Role of the Designer
Description of the Problem Description of the Solution
Paul Dunne GMIT
Definitions (2)
uStructured Analysis and Structured Designv different tools used to develop systemv often different teams used to do analysis and designv clear distinction between tasksv leads to the “Analysis/Design Wall”
Page 19
Paul Dunne GMIT
Definitions (3)
uWith newer development methods, the divide between analysis and design breaks downv the concept of seamlessnessv that an essential model is very difficult to develop without
reference to the implementation issuesv the increasing emphasis on requirements analysis
uSome commentators see onlyv Requirements Analysisv High-level Designv Low-level Design
u The debate rages on!
Paul Dunne GMIT
Definitions (4)
uSystems Analysisv Process of defining a problem, gathering the requirements and
developing an analysis model representing those requirementsv Describing the problem the system means to solve
uSystems Designv Process by which the analysis model is transformed into a model
which is capable of being implementedv Describing the solution to the problem
Page 20
Paul Dunne GMIT
Why do we need Analysis?
Paul Dunne GMIT
Why do analysis and design?
uAdd formalityuReduce errorsu Improve communication between participantsuGet the requirements right!u The cost of fixing analysis and design errors as one
moves from the analysis phase to the maintenance phase can increase by a factor of 100
uGenerate documentation
Page 21
Paul Dunne GMIT
Cost of Analysis/Design Errors
Paul Dunne GMIT
Source of Errors
Page 22
Paul Dunne GMIT
Types of Analysis/Design
u Top-down Analysis and Designv Structured Analysisv SADT
uObject-Oriented Analysis and Designv Object Modeling Technique (OMT)v Booch OOA&Dv Unified Modeling Language (UML)
uData-Driven Analysis and Designv Jackson System Designv Warnier-Orr Method
Paul Dunne GMIT
References
uPressman, R., Software Engineering: A Practitioner's Approach, McGraw-Hill, 2000 (Chapter 10).
uSommerville, I. and Sawyer, P., Requirements Engineering, Wiley, 1997.
