BMAN 10690 Integrative Team Project Week 2 Professor Linda A Macaulay

Download Report

Transcript BMAN 10690 Integrative Team Project Week 2 Professor Linda A Macaulay

BMAN 10690
Integrative Team Project
Week 2
Professor Linda A Macaulay
Overview
•
•
•
•
•
•
•
•
•
What is a requirement?
Requirements Engineering
Requirements Engineering Process
Areas of knowledge related to requirements
engineering
Types of requirements document
The Cooperation Requirements Capture (CRC)
method for generating user requirements
User Requirement document
Scope of solution
Task for 18th October
[email protected]
2
The Process of Application Design
User’s
present
job
Technological
options
Application
Design
Future
Application
[email protected]
3
What is a Requirement?
There are a number of definitions of the term
requirements. The most notable being the IEEEStandard 610 (1990):
1. A condition or capacity 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 system component to
satisfy a contract, standard, specification, or other
formally imposed documents.
3. A documented representation of a condition or
capability as in 1 or 2.
[email protected]
4
Requirements Engineering
Pohl (1993) in his paper on the ‘three dimensions of
requirements engineering’ provides one of the first
definitions of RE:
“Requirements Engineering can be defined as the
systematic process of developing requirements
through an iterative co-operative process of
analysing the problem, documenting the resulting
observations in a variety of representation formats,
and checking the accuracy of the understanding
gained.”
[email protected]
5
Requirements Engineering Process
concept
problem
analysis
feasibility and
choice of options
analysis and
modelling
requirements
documentation
Figure 5 Activities within Requirements
[email protected]
6
Areas of Knowledge Related to Requirements Engineering
Present Situation
Markets
Competitors
Strategy
Users present
Job
Organisation Government
Technological
Options
System
Design
Future
System
Future Situation
Markets
[email protected]
Competitors
Strategy
Organisation Government
7
Types of Requirements Document
M arket requirements document
e.g. market segmentation
User requirements document
e.g. BS 6719-1986
Software requirements document
e.g. IEEE Std. 830-1984
Three different ty p es of requirements document
[email protected]
8
The Cooperation Requirements Capture
Method for Generating User Requirements
A need for change is identified,
a new project is proposed.
CRC process
input
process
CRC outputs:
A description of the target users now and in the
proposed future situation.
output
An agreed list of requirements, including initial
task and object models
A shared understanding of the proposed system
[email protected]
9
CRC Process
[email protected]
10
User Requirement Document
1. Management Summary
(including the business case and a brief description of the proposed
system)
2. Organisation/Workgroups
2.1 Workgroup Control Sheets
2.2 Organisation Chart
2.3 Workgroup Table
2.4 Workgroup Description Checklists
3. Generic Users
3.1 Generic Users Control Sheets
3.2 Generic Users Description Checklists
4. Tasks
4.1 Task Control Sheets
4.2 Task Hierarchy
4.3 Task Description Checklists
[email protected]
11
User Requirement Document (Cont.)
5. Objects
5.1 Objects Control Sheets
5.2 Object Structures
5.3 Object Description Checklists
6. Interactions
6.1 User/Task/Object Interactions
6.2 Initial List of Requirements and Attributes
7.Consolidation
7.1 Statement of Credibility
7.2 Further Investigations Needed
8. Worth Proceeding?
8.1 User/Stakeholder Perspective
8.2 Business Perspective
8.3 Plan of Action
9. Conclusion
[email protected]
12
Scope of solution
1. Management Summary
(including the business case and a brief description of the proposed
system)
2. The Human Requirements
2.1 Description of the objectives of the commissioning organisation
2.2 List of the stakeholders together with their objectives
2.3 List of key workgroups and users and their objectives
3. The High Level Functional Requirements
3.1 List of work roles to be supported and why
3.2 Description of each work role in terms of users, objects and tasks
4. The Detailed Functional Requirements
4.1 Consolidated list of objects to be supported
4.2 Descriptions of each object together with details of user tasks
associated with each object
[email protected]
13
Scope of Solution (cont.)
5. The Quality Attributes
Quality attributes may include usability, reliability, portability,
performance, security, maintainability, acceptability
depending on the proposed system.
6. Organisation and User Assistance Requirements
6.1 Documentation requirements
6.2 Training requirements
6.3 User support
6.4 Human computer interface requirements
7. The Technological Requirements and Constraints
7.1 Known hardware requirements (user or supplier)
7.2 Known software constraints (user or supplier)
[email protected]
14
Overview of the Process
Perceived need for new system
Step 1:Business case
and initial description
Step 2:Workgroups
Find different potential
target users
Step 3: Users
YES
NO
Step 4: Tasks
Worth
proceeding
for other
business
reasons?
Feedback
probable
as the team
shares
understanding
of users
Step 5: Objects
Step 6: Interactions
Step 7: Consolidation
Cancel project
NO
Step 8:Worth
proceeding
from a user/
stakeholder
viewpoint?
YES
Validate understanding
of users
[email protected]
15
Workgroups: Overview
Each of the discussions concerning
workgroups, users, tasks and objects
includes a brainstorming session; an
evaluation session; a prioritisation session
and an analysis of change session.
[email protected]
16
Workgroups: LIST then CLASSIFY
Work Group
Title
Title 1
Title 2
Title 3
Relationship
Generic Users
Indicates the likely relationship of user or workgroup to the proposed system
1
Primary Relationship: Likely to be frequent, hands on users
2
Secondary Relationship: Likely to be occasional users or use the system through
an intermediary
3
Tertiary Relationship: Probably will not use the system, but may be affected by
it's use, or may influence it's purchase
CRC Stage 1 fig 2 , A Workgroup Table
[email protected]
17
Workgroups: select one and describe in detail and
assess change
Proposed System
Workgroup
Organisational & Soc ial Issues
Now
Propose d (e .g. 2 ye ars on)
Mi ssi on/O bje cti ve s
Autonomy
Cohe si on
De pe nde ncy on othe r Work-groups
S tructure and Dynami cs
Pre sti ge
CRC St age 1 fig 3, Workgroup : Organisat ional and Social Issues
[email protected]
18
Similarly for Users, Objects, and Tasks
Descrip tion Sheets
Generic Users
Relationship
Job
1: Primary User
2: Secondary User
3: Tertiary User
Person Organisation
YES: M eans that a Descrip tion sheet
has been comp leted for that user
NO: M eans it hasn't
CRC Stage 1 fig 4, List of generic users
[email protected]
19
Object Description Sheet
Proposed System
Objec t
Objec t Desc ription
Now
Propose d (e .g. 2 ye ars on)
De scri pti on
Acce ss to the
O bje ct
Manage me nt
Re pre se ntati on
Q ual i ty
CRc St age 1 fig 12, Object Descrip t ion Sheet
[email protected]
20
USER
Carries
Out a
May be
changeably
Task
Object
On an object
[email protected]
21
The Process of Application Design
User’s
present
job
Technological
options
Application
Design
Future
Application
[email protected]
22
This week: Understanding Users
Step 3 of Co-operative Requirements Capture
• Before Tuesday background research
• ON TUESDAY
– Thinktank Session
• List; Classify; Select Target Users to study in detail
• Prepare interview questions to learn more about target
users
• ON THURSDAY
– In class
• Conduct interviews in groups
[email protected]
23
Next Week
• STEP 4 of Co-operative Requirements
Capture
• By 18th October
– Initial User Requirements Document
[email protected]
24
Where to find lecture slides and
more details
www.lindamacaulay.com
Look under ‘Teaching’
[email protected]
25