September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I will answer based on the PMBOK. You have two types of scope: project scope (in charge of the project manager (PM)) and product scope (in charge of business analyst (BA)). Project scope is the WORK performed to deliver the product/service/result. Product scope are FEATURES AND FUNCTIONS that characterrize the product/service/result. The important thing is: Project scope is defined from Product scope. To know about requirements the best source is the IEEE. The definition about requirements inside the IEEE Std 1233 has been used into most (I think 95%) of any other documents talking about requirements including the PMBOK. The best thing inside the IEEE Std 1233 is that you will find how a well formed requirement will be state that is critical.
(A) A condition or capability needed by a user to solve a problem or achieve an objective.
(B) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, speciÞcation, or other formally imposed document.
So, to determine the product scope who have to have requirements on hand.
Vikash you may also wish to consult Business Analysis for Practitioners: A Practice Guide.
The simple answer is that Requirements are what the customer wants; ideally after performing interviews with key stakeholders and considering the expectations.
Scope is the work to be done - based on requirements (but Sergio explained well)
Please let me just one comment. I agree with David and Mounir. Just one little recomendation that I saw is critical to proceed with requirements (and I am not saying that generally speaking is not as Mounir stated above). Wants/Desires/Needs/etc have to be transformed into requirements. Here is where you can take a look to IEEE Std 1233 or to a seminal book of Gauss and Weinberg named "Exploring Requirements: Quality before design". And you can consult the PMI´s "Requirements Management for Practitioners: A Guide" . And as David stated take a look to the business analysis guide too.
All explanations are right and I look at it in “Zoom Out” view - you can say Helicopter View / Eagle View / Panoramic View / Visualization Technique / Milton Model (vague / abstract) thinking... whatever. Beauty of vagueness is "We cannot NOT Agree".
Sometimes detailing is not sufficient to explain though that is ultimate to get result.
Once elicitation of requirements is over, we get map (imagine all elicited requirements plotted across a paper covering 360 degree angle, compartmentalizing all types of requirements in a circular pie fashion, so we get an area with circumference, not uniform maybe, imagine single thread cobweb) of our requirements, we can draw a demarcation line for our requirement set of our project. These requirements are raw not so far selected for scope definition.
Then we will identify valid requirements (of course based on logic, and iteration) out of those collected raw requirements and demarcate our scope in the same diagram, outline might be amoeboid, but within the circumference of raw requirements. Now this is our scope, so called final, nobody knows what will come on the way of our project journey, to begin with our project work with the same.
Those non included requirements (which are lying out of scope circumference, but in the requirements boundary - requirements traceability matrix) are partially tagged as exclusion or under review. Not only these requirements, there are so many invisible / unknown requirements (new to appear in our mind during project progress – we can say rolling wave concept, it is driven by expectations which is submerged part of iceberg, encapsulated with beliefs and values, almost 89%) lying out of the scope boundary and we can say requirement boundary is greater than the scope boundary as scope boundary is fixed to begin the project. Therefore we can conclude requirement is superset of scope.
Now during project progress we will add or delete requirements (thru’ CCB or bypassing CCB, it is obvious, experience says) and our scope circumference will inflate out. We can say this phenomenon as scope reclamation (metaphorically river water interface recedes and we reclaim land – like that). This phenomenon is continued throughout the project till the end. And at the end once we get our desired product, stakeholders satisfied (success), we can claim we have included all requirements in the scope. Then the scope is final. Circumference of scope covers the circumference of requirement. Therefore, we can conclude scope is superset of requirement.
But if project fails, it indicates all requirements of customer are not included in scope, anyway missed. Can we say requirement circumference is still greater than scope circumference? Yes ! Therefore, in this case too we can conclude requirement is superset of scope.
I cannot imagine much more !
I like to use a simple example to distinguish between requirements, scope, solution, and tasks (the work to get it done):
"I need to get to work faster. I need more exercise. I need to be safe." are customer requirements.
The solution is a bicycle as it meets all of the requirements.
The scope may be:
* Procurement of a bicycle and some customizations such as a helmet and reflectors for safety.
* Customer 'training' delivery on product use and safety.
The work/tasks to achieve the project (using verbs to show action) is to procure the bike, ship the bike, assemble the bike, add the customizations and test the bike, deliver to the final product to the customer, deliver training, ensure the customer knows how to be safe by providing a map of safe bicycle routes for travel (process)
total agree with you Michelle Daigle
The Value is the difference between what the customer wants and what the customer needs, totally agree with Michelle.
Sorry, but is a big mistake to confuse needs with requirements. Each person that work with requirements must understand that she/he will elicit needs/wants/wishes/desires and after performing analysis those will be transformed into requirementes. The big mistake is do not do that. When you read that most of the project or initiatives fail because problem with requirements when you analyze the situation the problem is that requirements were never there. Most of the people start the project based on needs/wants/wishes/desires instead of requirements. How to know if I have a requirement on hand? First of all by especifing it following some quality standards like IEEE 1233. Second, by performing quality assurance and quality control on the requirements especification document.
Well done, Michelle Daigle. Better patent your illustration :-)
Please login or join to reply