250 likes | 269 Views
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
E N D
BMAN 10690 Integrative Team ProjectWeek 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
The Process of Application Design User’s present job Technological options Application Design 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): • A condition or capacity needed by a user to solve a problem or achieve an objective. • 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. • 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.”
The Cooperation Requirements Capture Method for Generating User Requirements A need for change is identified, a new project is proposed. input process CRC 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/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
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
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
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)
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: select one and describe in detail and assess change
USER Carries Out a May be changeably Task Object On an object
The Process of Application Design User’s present job Technological options Application Design 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’