04 - analysis concepts and requirements workflow
TRANSCRIPT
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
1/37
Object-Oriented & Classical Software Engineering, 7th Ed.
Stephen Schach, 2007
McGraw-Hill International Edition
Requirements and
Analysis Workflows
What must the new product be able to do?
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
2/37
Outline
Requirements Workflow
Analysis Workflow
Requirements
Requirements Engineering Activities
Modeling the Requirements (separate slides)
Validation the Requirements (separate slides)
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
3/37
Requirements Workflow
Objective:
To determine the clients needs and constraints
Tasks:
Understand the application domain
Build a business model
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
4/37
Definition of Terms
Concept Exploration
Preliminary investigation of the clients needs
Application Domain
The specific environment in which the target product is
to operate or to be used, e.g., banking, military
Business Model
A document (containing UML diagrams) to describe the
clients business processes
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
5/37
Domain Analysis
Domain
The general field of business or technology in which the
customers expect to be using the software
Domain Analysis involves learning background
knowledge to enable the software engineer to:
Communicate with users
Be able to understand the problem
Be able to make intelligent decisions
Lethbridge and Laganiere, 2005
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
6/37
Domain Analysis
Sources of information
Domain experts or people who work in a domain and
who have a deep knowledge of it
Books about the domain Existing software on the domain and its documentation
Lethbridge and Laganiere, 2005
Describe sources of information you can think of that can be
consulted in order to perform domain analysis in
Outline a short description of the information that you wouldneed to gather in order to perform analysis for
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
7/37
Analysis Workflow
Objective:
To analyze and refinethe requirements to achieve
the detailed understanding of the requirements
essential for Developing a software product correctly
Maintaining the software product easily
To specify product requirements using more
precise (or technical) language
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
8/37
Problem Definition and Scope
What is a Problem?
A difficulty the users or customers are facing
An opportunity that will result in some benefit such as
improved productivity or sales
What is a Solution?
Entails software development, or purchasing a software
Lethbridge and Laganiere, 2005
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
9/37
Requirement
A feature of the software or a description of
something the software is capable of doing inorder to fulfill the systems purpose(Old INTROSESlides)
A statement about what the proposed system
will do that all stakeholders agree must be made
true in order for the customers problem to be
adequately solved(Lethbridge and Laganiere, 2005)
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
10/37
Types of Requirements
Functional Requirement
Describes an interaction between the software andits environment (Old INTROSE Slides)
Describes what the system should do or theservices provided for the users or other systems
Lethbridge and Laganiere, 2005
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
11/37
Types of Requirements
Categories ofFunctional Requirement What inputs (data and commands) should the system accept
and under what conditions?
What outputs (screen, printer, I/O devices, servers) should
the system produce and under what conditions?
What data should the system store that other systems might
use?
What computations should the system perform?
The timing and synchronization of the above, if applicable
Lethbridge and Laganiere, 2005
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
12/37
Types of Requirements
Non-functional Requirement
Describes restriction on the software that limits
the choices for constructing a solution to the
problem (Old INTROSE Slides) Constraints that must be adhered to during
development
Limits the resources that can be used
Sets bounds on aspects of the softwares quality
Lethbridge and Laganiere, 2005
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
13/37
Non-Functional Requirements
Constraints on the design to meet the specified levels of
quality
Response time
Throughput e.g., transactions or computations per minute
Resource usage
Reliability
Availability
Recovery from failure
Allowances for maintainability and enhancement Allowances for reusability
Lethbridge and Laganiere, 2005
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
14/37
Non-Functional Requirements
Constraints on the environment and the technology of the
system
Platform
Technology to be used
Constraint on the project plan and development methods
Development process (methodology) to be used, e.g.,
specific testing approaches
Cost and delivery date
Lethbridge and Laganiere, 2005
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
15/37
Example
Functional Requirements
The software should allow different types of files to be
accessed.
The software should print student grades.
Non-functional Requirements
Reliability: The software should inform the user if a file
type is not supported (instead of terminating abruptly or
hanging).
Response Time: The software should print student grades
in 30 seconds.
Old INTROSE Slides
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
16/37
Levels of Functional Requirements
Business Requirements
Describe why the software is being built
Identify the benefits both customers and business
organization will reap from the software Help the company operate more efficiently (for
information systems) or compete successfully in
the marketplace (for commercial products)
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
17/37
Levels of Functional Requirements
User Requirements
Describe the tasks or business processes a user will
be able to perform with the software
Modeled using use case diagrams
Functional Requirements
Describe the specific system behaviors that must
be implemented into the software to enable theusers to accomplish their task
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
18/37
Levels of Functional Requirements
SystemRequirements
Describe the top-level requirements for a product
that contains multiple subsystemsthat is, a
system A system can be all software or it can include both
software and hardware subsystems
People are a part of a system, too, so certain
system functions might be allocated to human
beings
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
19/37
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
20/37
Non-Functional Requirements
Quality Attributes
Augment the description of the product's
functionality by describing the product's
characteristics in various dimensions that areimportant either to users or to developers
These characteristics include usability, portability,
integrity, efficiency, and robustness
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
21/37
Non-Functional Requirements
Constraints
Impose restrictions on the choices available to the
developer for design and construction of the
product
External Interfaces between the system and the
outside world (user, another software, and/or
hardware devices)
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
22/37
Software Feature
A set of logically related functional requirements
Provides a capability to the user
Enables the satisfaction of a business objective
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
23/37
Example: Word Processor
Business requirement:
The product will allow users to correct spelling errors
in a document efficiently.
What are its features?
What are its user requirements?
What are its functional requirements?
What quality attributes should it provide?
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
24/37
Product feature:
Spell checker
User requirements (tasks or use cases to support the productfeature):
Find spelling errors
Add word to global dictionary
Quality attribute
Usability
Efficiency
Example: Word Processor
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
25/37
Functional requirements or operations:
Finding a misspelled word
Highlighting a misspelled word
Displaying a dialog box with suggested replacements
Globally replacing misspelled words with corrected
words
Example: Word Processor
Wiegers, 2003
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
26/37
Requirements Development
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
27/37
Requirements Elicitation
Process of discovering the clients requirements
Communication-intensive process
The most difficult part is helping users figure out
what they want Methodology:
Interview
Survey or questionnaire
Observation Document review (forms, reports)
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
28/37
Document Review
Obtain copies of all input forms, both filled in and blank, and all
output reports, if possible.
How often it is produced?
How many copies are generated?
Who receives the copies?
Study the existing system documentation.
Deliverables that were performed
Policy manuals and specifications of procedures, programs, data, and interfaces
Written manuals and help files embedded in the software Negative documentation such as system errors, employee complaints
The documentations age is a clue to its reliability.
Old INTROSE Slides
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
29/37
Observation
Observe the current procedures.
Real operation vs. theoretical procedures written in the
documents
Obtain permission from both the person to be observed and thatpersons supervisor; and explain the purpose
Observe normal procedures and exceptional cases
Participatory Observation
Stay out of the way, making certain we do not interrupt ordisturb the activities in progress.
Old INTROSE Slides
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
30/37
Requirements Analysis
Problem identification and analysis
Process of refining and extending the initial set
of requirements elicited from the client
Organizational/process modeling
Systems analysts (or Business analysts) focus on
what, not how
Old INTROSE Slides
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
31/37
Requirements Analysis
The Myth of Stable Requirements
First law of system engineering [Bersoff]:
No matter where you are in the system life cycle,
the system will change, and the desire to changewill persist throughout the life cycle.
Users dont know what they want.
Old INTROSE Slides
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
32/37
Requirements Analysis
The Myth of Complete and Consistent Requirements
Large systems are viewed as wicked problems:
Diverse user community with different priorities Users are not the people who pay for the system
Old INTROSE Slides
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
33/37
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
34/37
Requirements Specification
A document that describes the system to be
developed in a format that can be reviewed,
evaluated, and approved in a systematic way
(Cleland-Huang, 2005) Constitutes a contract
Should not include imprecise terms like suitable,
convenient, ample, enough, etc.
Essential for both testing and maintenance In the Unified Process, a set of UML artifacts
constitute the specification document
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
35/37
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
36/37
Requirements Specification
Common problems:
Ambiguous two or more different interpretations
or meanings
Incomplete missing some relevant fact orrequirement
Contradictions
-
8/2/2019 04 - Analysis Concepts and Requirements Workflow
37/37
References
Jane Cleland-Huang, 2005. Software Requirements.IEEE
Software Engineering, 3rd ed., Volume 1.
T. Lethbridge & R. Laganiere, 2005. Object-oriented
Software Engineering: Practical Software Development
using UML and Java. London: McGraw-Hill
I. Sommerville, 2004. Software Engineering, 7th ed.
Pearson Education
Karl Wiegers, 2003. Software Requirements, 2nd ed.
Washington: Microsoft Press.
" href="https://vdocument.in/workflow-concepts-and-techniques-universit-de-skaf-hpmwikiuploadsmainlectureworkflow.html">Workflow Concepts and Techniques - Université de Nantespagesperso.lina.univ-nantes.fr/~skaf-h/pmwiki/uploads/Main/Lecture... · Workflow Concepts and Techniques ... AssessorProcessResponse/ns1:level"/>