Embed Size (px)
Citation preview
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
The Process of Application Design
User’s present
job
Technological options
ApplicationDesign
Future Application
What is a Requirement?
There are a number of definitions of the term requirements. The most notable being the IEEE-Standard 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.
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.”
Requirements Engineering Process
concept
problem analysis
feasibility and choice of options
analysis and modelling
requirements documentation
Figure 5 Activities within Requirements
Areas of Knowledge Related to Requirements Engineering
Users present Job
Technological Options
System Design
Future System
Present Situation
Future Situation
Competitors Strategy OrganisationMarkets Government
Competitors Strategy OrganisationMarkets Government
Types of Requirements Document
Market 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 types of requirements document
The Cooperation Requirements Capture Method for Generating User
Requirements
A need for change is identified, a new project is proposed.
input
CRC process process
CRC outputs:A description of the target users now and in the proposed future situation.
An agreed list of requirements, including initial task and object models
A shared understanding of the proposed system
output
User Requirement Document
1. Management Summary(including the business case and a brief description of the proposed system)
2. Organisation/Workgroups2.1 Workgroup Control Sheets2.2 Organisation Chart2.3 Workgroup Table2.4 Workgroup Description Checklists
3. Generic Users3.1 Generic Users Control Sheets3.2 Generic Users Description Checklists
4. Tasks4.1 Task Control Sheets4.2 Task Hierarchy4.3 Task Description Checklists
User Requirement Document (Cont.)
5. Objects5.1 Objects Control Sheets5.2 Object Structures5.3 Object Description Checklists
6. Interactions6.1 User/Task/Object Interactions6.2 Initial List of Requirements and Attributes
7.Consolidation7.1 Statement of Credibility7.2 Further Investigations Needed
8. Worth Proceeding?8.1 User/Stakeholder Perspective8.2 Business Perspective8.3 Plan of Action
9. Conclusion
Scope of solution1. Management Summary
(including the business case and a brief description of the proposed system)
2. The Human Requirements2.1 Description of the objectives of the commissioning organisation2.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 Requirements3.1 List of work roles to be supported and why3.2 Description of each work role in terms of users, objects and tasks
4. The Detailed Functional Requirements4.1 Consolidated list of objects to be supported4.2 Descriptions of each object together with details of user tasks associated with each object
Scope of Solution (cont.)
5. The Quality AttributesQuality attributes may include usability, reliability, portability, performance, security, maintainability, acceptability depending on the proposed system.
6. Organisation and User Assistance Requirements6.1 Documentation requirements6.2 Training requirements6.3 User support6.4 Human computer interface requirements
7. The Technological Requirements and Constraints7.1 Known hardware requirements (user or supplier)7.2 Known software constraints (user or supplier)
Overview of the ProcessPerceived need for new system
Step 1:Business case and initial description
Step 2:Workgroups
Step 3: Users
Step 4: Tasks
Step 5: Objects
Step 6: Interactions
Step 7: Consolidation
Validate understanding of users
YES
Step 8:Worth proceeding from a user/ stakeholder viewpoint?
NO
Worth proceeding for other business reasons?
Feedback probable as the team shares understanding of users
NO
Cancel project
Find different potential target users
YES
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.
Workgroups: LIST then CLASSIFY
CRC Stage 1 fig 2 , A Workgroup Table
Work Group Title
Relationship
Generic Users
Secondary Relationship: Likely to be occasional users or use the system through an intermediary
Indicates the likely relationship of user or workgroup to the proposed system
1
2
3
Primary Relationship: Likely to be frequent, hands on users
Tertiary Relationship: Probably will not use the system, but may be affected by it's use, or may influence it's purchase
Title 1 Title 2 Title 3
Workgroups: select one and describe in detail and assess change
CRC Stage 1 fig 3, Workgroup: Organisational and Social Issues
Proposed System
Workgroup
Organisational & Social Issues
Now Proposed (e.g. 2 years on)
Mission/Objectives
Autonomy
Cohesion
Dependency on other Work-groups
Structure and Dynamics
Prestige
Similarly for Users, Objects, and Tasks
CRC Stage 1 fig 4, List of generic users
Generic Users Relationship
Description Sheets
Job Person Organisation
1: Primary User 2: Secondary User 3: Tertiary User
YES: Means that a Description sheet has been completed for that user NO: Means it hasn't
Object Description Sheet
CRc Stage 1 fig 12, Object Description Sheet
Proposed System
Object
Object Description
Now Proposed (e.g. 2 years on)
Description Access to the Object Management Representation Quality
The Process of Application Design
User’s present
job
Technological options
ApplicationDesign
Future Application
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
Next Week
• STEP 4 of Co-operative Requirements Capture
• By 18th October– Initial User Requirements Document
Where to find lecture slides and more details
www.lindamacaulay.com
Look under ‘Teaching’
