Upload
daniel-singleton
View
215
Download
0
Embed Size (px)
Citation preview
1
SOFTWARERequirements Engineering
CP7007
Prof.Dr. B.Chandramouli
2
SOFTWARE REQUIREMENTS ENGINEERING
UNIT I DOMAIN UNDERSTANDING
UNIT II REQUIREMENTS ELICITATION
UNIT III FUNCTIONAL REQUIREMENTS
UNIT IV QUALITY ATTRIBUTES
AND USER EXPERIENCE
UNIT V MANAGING REQUIREMENTS
3
Syllabus Unit I
DOMAIN UNDERSTANDING Introduction
Types of requirements
Requirements engineering process
Validating requirements
Requirements and design
Requirements and test cases
Introduction to business domain – Problem analysis – Fish bone diagram – Business requirements – Business process modeling – Business use cases – Business modeling notations
UML Activity diagrams
4
The Requirements Problem: Standish Report, 1995
Survey of 350 US companies, 8000 projects8000 projects
(partial success = partial functionalities, excessive costs, big delays)
Major source of failure: poor requirements engineering 50% responses
5
The Requirements Problem: European Survey, 1996
Coverage: 3800 EUR organizations, 17 countries
Main software problems perceived to be in...
– requirements specification
> 50% responses
– requirements evolution management
50% responses
[European Software Institute, 1996]
6
Domain Understanding
Studying the system-as-is– Business organization: structure, dependencies, strategic
objectives, policies, workflows, operational procedures, ...– Application domain: concepts, objectives, tasks,
constraints, regulations, ...
– Strengths & weaknesses of the system-as-is
Identifying the system stakeholdersstakeholders:– Groups or individuals affected by the system-to-be, who
may influence its elaboration and its acceptance– Decision makers, managers, domain experts, users,
clients, subcontractors, analysts, developers, ...
ProductsProducts: Initial sections for preliminary draft proposal Glossary of terms
7
IntroductionIntroductionto Fundamentals of REto Fundamentals of RE
8
Definition
What is Requirements Engineering (RE) ?
– The problem world & the machine solution
– The scope of RE: the WHY, WHAT and WHO dimensions
– Types of statements involved: descriptive vs. prescriptive
– Categories of requirements: functional vs. non-functional
– The requirements lifecycle: actors, processes, products
– Target qualities and defects to avoid
– Types of software projects ( Green field, Single product, Multiple
line product, Inhouse, Outsourced, Customer driven, market
driven etc..)
– Requirements in the software lifecycle
– Relationship to other disciplines
9
Fundamentals of RE: outline
start
ElicitationElicitation
alternative options
agreedrequirements
documented requirements
consolidatedrequirements
RE products and processes
10
Fundamentals of RE: outline
start
Elicitation EvaluationEvaluation
alternative options
agreedrequirements
documented requirements
consolidatedrequirements
RE products and processes
11
Fundamentals of RE: outline
start
Elicitation Evaluation
alternative options
agreedrequirements
documented requirements
consolidatedrequirements
SpecificationSpecification
RE products and processes
12
Fundamentals of RE: outline
start
Elicitation Evaluation
alternative options
agreedrequirements
documented requirements
consolidatedrequirements
SpecificationQuality assuranceQuality assurance
RE products and processes
13
Fundamentals of RE: outline
start
Elicitation Evaluation
alternative options
agreedrequirements
documented requirements
consolidatedrequirements
SpecificationQuality assurance
RE products and processes
14
Fundamentals of RE: outline
start
Unit2: Elicitation
Unit 2:Evaluation
alternative options
agreedrequirements
documented requirements
consolidatedrequirements
Unit 3: Specification
Unit 4:Quality assurance
RE products and processes
Unit 5: Evolution management
15
RE: A Preliminary Definition
CoordinatedCoordinated set of activitiesactivities ...
– for exploringexploring, evaluatingevaluating, documentingdocumenting, consolidatingconsolidating,
revisingrevising and adaptingadapting the objectivesobjectives, capabilitiescapabilities,
qualitiesqualities, constraintsconstraints & assumptionsassumptions on a software-
intensive systemsystem
– based on problemsproblems raised by the system-as-isas-is and
opportunitiesopportunities provided by new technologies
16
The Scope of RE: the WHY, WHAT, WHO Dimensions
ObjectivesWHYWHY
a new system?
WHATWHAT services?
WHOWHO will be
responsiblefor what ?
satisfy
assignment
requirements, constraints,assumptions
problems, problems, opportunities,opportunities,
system knowledgesystem knowledge
System-to-beSystem-as-is
17
Requirements in the Software Lifecycle
RequirementsDocument
Project estimations(size, cost, schedules)
Project workplan
Software prototype,mockup
Follow-up directives
Software architecture
Call for tenders,proposal evaluation
Quality Assurancechecklists
Project contract
Software evolutiondirectives
Software documentation
Acceptance test data
Implementationdirectives
User manual
RE, system design & software architecture design are inevitably intertwined
The RD impacts on many software artifacts
18
The requirements engineering process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
19
19
Requirements Engineering Activities
Feasibility studyDetermine if the user needs can be satisfied with the available technology and budget.
Requirements analysis
Find out what system stakeholders require from the system.
Requirements definition
Define the requirements in a form understandable to the customer.
Requirements specification
Define the requirements in detail. (Written as a contract between client and contractor.)
20
Problems of Requirements Analysis
Various problems typically arise:
– Stakeholders don’t know what they really want
– Stakeholders express requirements in their own terms
– Different stakeholders may have conflicting requirements
– Organisational and political factors may influence the system requirements
– The requirements change during the analysis process.
– New stakeholders may emerge.
21
The Requirements Analysis Process
Requirementsvalidation
Domainunderstanding
Prioritization
Requirementscollection
Conflictresolution
Classification
Requirementsdefinition andspecification
Processentry
22
Categories of Requirements
Functional requirements: Functional requirements: prescribe what services the software-to-be should provide
– capture intended software effects on environment, applicability conditions
– units of functionality resulting from software operations
“The software shall control the acceleration of all trains”
Non-functional requirements: Non-functional requirements: constrain how such services should be provided
– QualityQuality requirements: safety, security, accuracy, time/space performance, usability, ...
– Others: compliance, architectural, development reqs
– To be made precise in system-specific terms
“Acceleration commands shall be issued every 3 seconds to every train”
23
Types of Non-functional Requirements
Performancerequirements
Spacerequirements
Usabilityrequirements
Ef ficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
24
Requirements Validation
Requirements must be written so that they can be objectively validated and verified.
Imprecise:– The system should be easy to use by experienced
controllers and should be organised in such a way that user errors are minimised.Terms like “easy to use” and “errors shall be minimised” are useless as specifications.
Verifiable:– Experienced controllers should be able to use all the
system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.
25
Precise Requirements Measures (I)
Property Measure
SpeedProcessed transactions/secondUser/Event response timeScreen refresh time
Size K Bytes; Number of RAM chips
Ease of useTraining timeRate of errors made by trained usersNumber of help frames
26
Precise Requirements Measures (II)
Property Measure
ReliabilityMean time to failureProbability of unavailabilityRate of failure occurrence
RobustnessTime to restart after failurePercentage of events causing failureProbability of data corruption on failure
PortabilityPercentage of target dependent statementsNumber of target systems
27
Requirements To Design
A requirements specification defines what the customer wants
A design specification defines how you satisfy what the customer wants.
– To go from step 1 to 2
First step is analysis and elicitation - to study the problem of input and output requirements carefully to make sure they are understood and make sense
Design starts with pictorially (UML) represent the analysis
28
Requirements To Design
Use case: list of the user actions and system responses for a particular sub-problem in the order that they are likely to occur
Sequence diagram: shows all the objects involved in this use case across the horizontal axis, time is shown along the vertical axis
Class diagram
Component diagram
Activity diagram
State Transition diagram
Precondition: a statement of any assumptions or constraints on the method data before the method begins execution
Postcondition: a statement that describes the result of executing a method
29
Requirements To Design
– UML diagrams are a design tool to illustrate the interactions between
• Classes
• Classes and external entities
– For better understanding Abstraction, Refining are used
– For better data design Inheritance, Information Hiding are used
– For better structure design Modularity, Architecture are used
30
Requirements to Testing - Traceability
Traceability is concerned with the relationships between requirements, their sources and the system design
Source traceability– Links from requirements to stakeholders who proposed
these requirements;
Requirements traceability– Links between dependent requirements;
Design traceability– Links from the requirements to the design;
31
CASE tool support
Requirements storage– Requirements should be managed in a secure, managed
data store.
Change management– The process of change management is a workflow process
whose stages can be defined and information flow between these stages partially automated.
Traceability management– Automated retrieval of the links between requirements.
32
Business Domain
3333
Background
A key component of Business Modeling (Domain Analysis) - in addition to Business Use Case Model and Business Object Model and other artifacts - is the Domain Model– Recall the Business Model is not only a graphical model, but
also other artifacts such as the Business Vision, Business Rules, Business Glossary, Business Risk List, and the Domain Model.
– All relate to the enterprise / organization.
– The Domain Model contains Key Abstractions (business / technology)– Is a Visual Model of business entities, relationships, multiplicities, and
more.
Prior to embarking on gathering requirements and capturing them via Use Cases (application use cases, requirements use cases, that is…), we need to understand the key entities in the business domain.
343
Domain Modeling - an Introduction
Domain Modeling is the task of discovering “objects” (classes, actually) that represent those business entities and concepts.
Recognize that the domain model will be a superset of your entity classes needed for your application development.– These class diagrams – later on - will likely contain some of the
entities found in your domain model.
– These appear similar to ERDs, but they are not the same.
• Fully-attributed list (not a schema or physical database design…)
3535
Domain Modeling - continued
Domain Models sometimes considered ‘informal’ class diagrams.
Developed as part of domain analysis (business modeling)
The ‘classes’ (entities) represent what you have learned about various ‘things’ (entities) and relationships between/among them in the business domain itself.
As a Visual Model, this model helps in understanding the domain.
Also serves as a Glossary, in that the entities will contain attributes and other defining qualities.– Think ‘Customer, ’ ‘Product Line’ etc.
3636
Domain Modeling - continued
The Domain Model: – Does NOT wholly support requirements analysis (ahead).– Is not INTENDED to…– Addresses entities in the domain of the organization –
that may be quite apart (superset) from a computer application that may use them.
– Are normally not concerned with representations of • inheritance, • polymorphism, etc, but can show aggregation,
multiplicities, etc.• (as we would be when embarking on development of an
application.)
3737
Domain Modeling - continued
In requirements analysis – – as part of gathering information on the application to
be developed,
– we develop class diagrams - contain entities (classes) taken from the domain model.
But the class diagrams (for development) will represent data that will be stored and manipulated by the application.
3838
Domain Modeling - continued
Models produced as part of requirements analysis (ahead lectures) will contain:
– Entity classes – • some may be derived from Domain Model,
– Boundary classes – • used for the user interface and external system interfaces
– Control Classes • used for controlling logic and business rules, and, in
general, orchestrating the application functions.
3939
So, what do we do?
Doing domain modeling is very important. Don’t want to spend too much time trying to model
everything!!! Yet we need to have a good starting point for requirements
analysis to solve the ‘problem.’
So, our domain modeling approach is to develop an ‘initial’ set of business entities (nouns).
This is a a static model of the domain by finding appropriate entities that represent the real key abstractions in the domain.– A ‘key abstraction’ example is Customer, Product, Account,
etc. – Serve to underpin system development later.
400
Developing Entities for Domain Model
Sources (again) of Domain Knowledge. Here are a few:– Interviews– Questionnaires– Quarterly Reports– Mission Statements– Subject Matter Experts (SMEs)– Newsletters– Web pages– A company’s e-business….
Look for nouns in these sources! – these are candidate classes in the domain model.– More examples: Menu, Customer, Food order, Payment, On-line order…
Things!
– Customer (class with attributes) ‘orders’ (relationship) Food (class with attributes)
– Capture graphically! – ‘Customer’ and ‘Food’ are entities related by ‘Orders’ with
multiplicity 1..n.
411
Developing Domain Entities
Read sources very closely; Capture these ‘nouns’ and noun phrases. Look for the ‘things’ in the domain…
Possessive phrases generally indicate that the nouns should be attributes rather than objects. – Try to identify attributes but omit operations.
Build associations (and name them) between domain entities Add multiplicities carefully Don’t worry about aggregations and association classes and much
more unless these relationships are clearly evident.
Model in some tool.
42
Problem-Analysis-Modeling
- Requirements analysis
- Flow-oriented modeling
- Scenario-based modeling
- Class-based modeling
- Behavioral modeling
’005
43 3
Goals of Analysis Modeling
Provides the first technical representation of a system
Is easy to understand and maintain
Deals with the problem of size by partitioning the system
Uses graphics whenever possible
Differentiates between essential information versus implementation information
Helps in the tracking and evaluation of interfaces
Provides tools other than narrative text to describe software logic and policy
44
A Set of Models
Flow-oriented modeling – provides an indication of how data objects are transformed by a set of processing functions
Scenario-based modeling – represents the system from the user's point of view
Class-based modeling – defines objects, attributes, and relationships
Behavioral modeling – depicts the states of the classes and the impact of events on these states
45
Requirements Analysis
46 6
Purpose
Specifies the software's operational characteristics Indicates the software's interfaces with other system
elements Establishes constraints that the software must meet Provides the software designer with a representation of
information, function, and behavior– This is later translated into architectural, interface,
class/data and component-level designs
Provides the developer and customer with the means to assess quality once the software is built
47 7
Overall Objectives
Three primary objectives– To describe what the customer requires– To establish a basis for the creation of a software design– To define a set of requirements that can be validated once
the software is built
All elements of an analysis model are directly traceable to parts of the design model, and some parts overlap
48 8
Analysis Rules of Thumb
The analysis model should focus on requirements that are visible within the problem or business domain – The level of abstraction should be relatively high
Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the following– Information domain, function, and behavior of the system
The model should delay the consideration of infrastructure and other non-functional models until the design phase– First complete the analysis of the problem domain
The model should minimize coupling throughout the system– Reduce the level of interconnectedness among functions and classes
The model should provide value to all stakeholders The model should be kept as simple as can be
49 9
Domain Analysis
Definition– The identification, analysis, and specification of common, reusable capabilities within a specific application domain– Do this in terms of common objects, classes, subassemblies, and frameworks
Sources of domain knowledge– Technical literature– Existing applications– Customer surveys and expert advice– Current/future requirements
Outcome of domain analysis– Class taxonomies– Reuse standards– Functional and behavioral models– Domain languages
50 50
Analysis Modeling Approaches
Structured analysis– Considers data and the processes that transform the data as
separate entities
– Data is modeled in terms of only attributes and relationships (but no operations)
– Processes are modeled to show the 1) input data, 2) the transformation that occurs on that data, and 3) the resulting output data
Object-oriented analysis– Focuses on the definition of classes and the manner in which they
collaborate with one another to fulfill customer requirements
51
Fishbone diagram
Cause – effect diagram
Ishikawa diagram
52
53
54
Business Process and management
Business Process : A set of logically related tasks performed to achieve a defined business outcome
Business Process Management(or BPM) refers to activities performed by organizations to manage and, if necessary, to improve their business processes
55
Business Process Management Notation
Business Process Modeling Notation (BPMN) is a graphical notation that describes the logic of steps in a business process
Why is it important to model with BPMN?
• BPMN is an internationally accepted process modeling standard.
• BPMN is independent of any process modeling methodology.
• BPMN creates a standardized bridge which reduces the gap between business processes and their implementation.
• BPMN enables you to model processes in a unified and standardized way so that everyone in an organization can understand each other
56
BPMN - TASK
Task: A task is carried out when the work in the process is not broken down into more detail. It is executed by one person and/or one application.
57
BPMN – Sub Process
Subprocess: A Subprocess is a compound activity included in a process. It is compound because it includes a series of activities and a logical sequence (process) indicating that it can be analyzed in more detail. Visually it can be “collapsed” or “expanded
58
59
Unified Modeling Language
A visual modeling language A standardized general-purpose modeling
language in the field of software engineering. Used to specify, visualize, construct and
document the artifacts of an object-oriented
software -intensive system under development A set of 9 diagrams (UML 1.4) and 13 diagrams
(UML 2.0) Not an industry standard but used widely
60
UML
Is not a S/W development methodologies
– Descriptive not prescriptive • Combines best practices from
• Data modeling (ex: ER diagram)• Business modeling (ex: Workflows)• Object modeling, and• Component modeling
• Combines• Booch method (G Booch)• OMT – Object modeling Techniques (J Rumbaugh)• OOSE (E Jacobson)
• An extensible language– Stereotypes, profiles
61
UML Users
• Architect
• Domain expert
• Designer
• Programmer/Developer
• Instructor
62
UML 2.0 Diagrams
63
Important UML Diagrams
64
Lets Discuss
• Use Case Diagram ( represents a Functional model ) Describes the functionality from user point of view)
• Sequence Diagram Describes the internal behavior as a sequence of messages
exchanged between a set of objects
• Statechart Describes the behavior in terms of states of individual objects and
its transitions
• Activity Diagram Describes the system behavior in terms of sequence of activities
• Class Diagram ( represents a Object model ) Describes the structure of the system in terms of objects, attributes,
associations and operations
65
Use cases
Define system functional requirements in terms of Actors and Use cases– Each use case specify a piece of functionality– A use case can be elaborated in terms of sequence
of interactions between Actor and the domain objects
– Simple use cases may involve only one interaction– More complicated use cases may involve several
interactions
66
Example: Use case Diagram
67
Sequence Diagram
Shows sequence of object interactions in a use case Emphasis on messages passed between objects
– Objects represented by vertical lines
- Actor is on extreme left of page
– Messages represented by labeled horizontal arrows
- Only source and destination of arrow are relevant
- Message is sent from sending object to receiving object
– Time increases from top of page to bottom– Spacing between messages is not relevant– Message sequence numbering is optional
68
Example: Sequence Diagram
69
State Chart
Graphical representation of finite state machine
States are rounded boxes Transitions are arcs State chart relates events and states
– Event– Causes change of state– Referred to as state transition
State represents interval between successive events
Initial state– Arc with black ball at end
70
Example: State Charts
71
Activity Diagram
Models a process workflow
Different from State chart
(A State chart models states of an object)
Models concurrency and synchronization
Models normal and alternate flow of
control in the same diagram
• Can be combined with a state chart
72
Example: Activity Diagram
73
Class Diagram
Objects and Classes
Objects represent “things” in real world– Provide understanding of real world– Form basis for a software solution
An Object is a single “thing”– E.g., John’s car , – Mary’s account etc..
A Class (object class) is a “blue print” of
objects with the same (similar) characteristics
– E.g., account, employee, car, customer
Each object has an identity and is distinguishable from others in the class
74
Example: Class Diagram
75
One case study
End of Unit 1