Requirements Factoring Themes

Slides:



Advertisements
Similar presentations
Better Specifications. What is a Specification? A Statement of the Customers Needs In the Form of Required Characteristics of a Product A Component of.
Advertisements

1 Presented By: Sonya Hawkins.  Discuss Scope  Discuss Requirements 2.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CS 411W - Notes Product Development Documentation.
:: 1 :: What is a requirement? Standard Definition Something the product must do or a quality the product must have. More Ways to Characterize Something.
Intro to Scrum. What is Scrum? An answer to traditional “fixed cost / strict requirements” contracts which had very high rates of failure Recognizes the.
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Software Requirements
Object Oriented Software Development Modelling information systems OOSAD Booklet Chapter 3 Lecture: Week 2 Brian Farrimond.
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
1 Software Requirements Specification Lecture 14.
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
Release & Deployment ITIL Version 3
What is Business Analysis Planning & Monitoring?
S/W Project Management
CC20O7N - Software Engineering 1 CC2007N Software Engineering 1 Requirements Engineering Practices with Techniques.
Typical Software Documents with an emphasis on writing proposals.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Negotiation and Specification Process
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems.
Transforming how companies work with technology. Requirements Seminar.
Requirement Review & Verification CS 330 – Fall 2002 Rania Elnaggar.
CPSC 372 John D. McGregor Module 2 Session 1 More on requirements and the Investment Decision.
Ch 4 - Learning Objectives Scope Management You should be able to: n Discuss the relationship between scope and project failure n Describe how strategic.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
12/10/15.  It is a Cross Life Cycle Activity (CLCA) that may be performed at any stage ◦ In fact, some part of it (e.g. risk analysis and management)
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Lecture 2 Developing Requirements
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
1 Quality Attributes of Requirements Documents Lecture # 25.
Project management Topic 1 Project management principles.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
CS628 - Object Oriented Analysis And Design. The Four Pillars of Successful Software Development -Avoid Classic Mistakes -Apply Development Fundamentals.
1 OOAD Mehwish Shafiq. 2 The Requirements specification must provide sufficient information to enable the system to be constructed “ successfully. ” Functional.
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
 System Requirement Specification and System Planning.
The Quality Gateway Chapter 11. The Quality Gateway.
SEG 3300 W RITING B ETTER R EQUIREMENTS Supplement to Chapter 4 Source: Ian Zimmerman, Daniel Amyot Telelogic, July 9, 2001.
Bernd Bruegge and Allen Dutoit Requirements Process The requirements process consists of two activities: Requirements Elicitation: Definition of the system.
Purchasing Decisions And Business Strategy
IS 455 Project Management – What is a project?
Project Planning: Scope and the Work Breakdown Structure
Processes and threads.
Scope Planning.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Lecture 2 Developing Requirements
Requirements Validation – II
Requirements Management
Introduction to Requirements
Software Requirements
Business Process Measures
Chapter 5: Project Scope Management
Understand the principles of effective decision making
IDEF1X Standard IDEF1X (Integrated Definition 1, Extended) was announced as a national standard in 1993 It defines entities, relationships, and attributes.
Software Requirements analysis & specifications
Biology EOC Must pass EOC to graduate from high school
The Owner’s Project Requirements (OPR) Process
Requirements Analysis
Daniel Siahaan February 2012
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Project Management Process Groups
Biology EOC Must pass EOC to graduate from high school
Topic 9: Requirements Definition and Prioritisation
Software Reviews.
How to Scope a Project.
Presentation transcript:

Requirements Factoring Themes Problem Decomposition Actionable problem statement(s) Functions Processes Affected Systems Affected Roles Data Stakeholder needs Solution Boundaries Deadlines Controls Cost limits Interim or permanent Evolution or big bang Local, regional, or global Process synchronization points Problem Context Business impacts Acceptable trade offs Potential changes for problem definition Influences Priority Audiences User Functional Solution Constraints Other

Quality Measures Cheat Sheet Definition Questions to Ask Complete All conditions of use or action are specified. Requirement as stated can be understood on its own. What are the conditions for this requirement to apply? What exceptions are there? Consistent Does not contradict other requirements or itself. Is this in opposition to other requirements? Does this overlap or restate other requirements? Correct As stated accurately states the business need. As stated, does this reflect the business need in the business case? Have the business rules been confirmed by the correct SME? Modifiable Stated so that there changes to scope or applicability can be made completely and consistently without changes to other requirements Is the requirement stated to stand on its own? Is the scope of the requirement defined? Prioritized / categorized Stakeholder has identified where this requirement ranks based on a category scheme Sample categories: Mandatory or optional Order of delivery: ASAP, first, second…., by x, 30 days later … Interim solution needed; only a temporary solution needed Connection with other requirements Verifiable Objective criteria provided to state when requirement has been satisfied. Do the requirements rely on subjective judgment? Are the criteria specified for all conditions of occurrence or use? Traceable Requirement is sufficiently unique that it can be identified and traced Is there a unique id? Are related requirements identified? Parent / child / dependent Unambiguous Clearly stated with no ambiguity or vagueness Are there multiple meanings for the statement? Is the requirement too general, applying in too many cases? Necessary A need for the business to achieve the goals of the business case 1. Is this requirement met in the current situation? If so, does the solution need to be changed? Feasible Requirement can be satisfied or has been satisfied Has any other organization met this requirement? Can our organization deliver a solution? Can any organization deliver a solution? Understandable Requirement does not contain specialized or obscure language that is unfamiliar to stakeholders and is stated directly and simply. Can you phrase the requirement for an executive? Can you phrase the requirement for an accountant? Can you phrase the requirement for the customer service department? Can you phrase the requirement for a developer? Quality Measures Cheat Sheet In a 1988 study for the U.S. Air Force, the Mitre Corporation compiled this list of common practices that lead to “fuzzy” requirements. Some of the items that were listed: Incomplete lists that end in etc., and/or, TBD(to be determined), including but not limited to, … Imprecise verbs such as handled, processed Vague words such as generally, normally, practical Unintended implications of certainty: always, never, every Passive voice phrases: the counter is set Pronouns for which references are not clear Unclear comparatives: earlier, easiest, most valuable Unquantified attributes: flexible, intuitively obvious, efficient, organized Ambiguous words: quickly, adjacent, last Contractually troublesome phrases: where applicable, to the extent practical