In this chapter, we describe requirements
process that we have derived from our years of working in the requirements
arena.
Requirements revelation ought to be viewed as an essential precursor of any
Requirements revelation ought to be viewed as an essential precursor of any
development activities, however, it ought to likewise be seen as something that can be
led rapidly, now and then casually, now and again covering with resulting structure and development exercises, however, never ignored. As we experience the procedure, we depict it as though you were working with a fresh out of the box new item—that is, creating something without any preparation. We adopt this strategy to keep away from, for the occasion, getting caught in the requirements that are a piece of all support ventures. Afterward, we will talk about prerequisites for those circumstances when the item exists and changes to it are required.
The Case Study
The IceBreaker project is to develop a product that predicts when and
where ice will form on roads, and to schedule trucks to treat the roads with
de-icing material. The new product will enable road authorities to more accurately predict ice formation, schedule road treatments more precisely, and
thereby make the roads safer. The product will also reduce the amount of
de-icing material needed, which will help both the road authority’s finances
and the environment. so just giving relevance with our company TD Bank they always need to find a path where they can run their business smoothly and in a proper way.
Project Blastoff
Imagine launching a rocket. 10 – 9 – 8 – 7 – 6 – 5 – 4 – 3 – 2 – 1 – blastoff! If all it
needed were the ability to count backward from 10, then even Andorra1 would
have its own space program. The truth of the matter is that before we get to
the final 10 seconds of a rocket launch, a lot of preparation has taken place.
The rocket has been fueled, and the course plotted—in fact, everything that
needs to be done if the rocket is to survive and complete a successful mission. so whenever TD bank is doing something this countdown help as they focus on each and every small detail of the project.
Trawling for Requirements
Once the blastoff is completed, the business analysts start trawling the work
to learn and understand its functionality—“What’s going on with this piece
of the business, and what do they want it to do?” For convenience and consistency, they partition the work context diagram into business use cases.
so here comes the part of business analyst one of the most important in every field the same as every company TD bank also takes into consideration of their business analyst in most of the cases.
Quick and Dirty Modeling
Models can be used at any time in the Volere life cycle; in Figure 2.1, we show
this activity as “Prototype the Work.” There are, of course, formal models
such as you would find in UML or BPMN, but a lot of the time business
analysts can make productive use of quick sketches and diagrams to model
the work being investigated. One quick and dirty modeling technique we
should mention here is using Post-it notes to model functionality; each note
can be used to represent an activity, and the notes can be rapidly rearranged
to show different ways the work is done or could be done.
Writing the Requirements
A major problem in system development is misunderstood requirements. To
avoid any misunderstanding, the analysts must write their requirements in
an unambiguous and testable manner, and at the same time ensure that the
originating stakeholder understands and agrees with the written requirement before it is passed on to the developers. In other words, the analysts
write the requirements so as to ensure that parties at either end of the development spectrum are able to have an identical understanding of what is
needed.
The Snow Card is the guide to how to write a individual requirement and its attributes. On the snow card we have:
ReplyDelete• the requirement# and type
• the description: one phrase to describe the intention of the requirement.
• Rationale: A justification for this requirement.
• Originator: The responsible person to create the requirement.
• Fit Criterion: The measurement of the requirement.
• Customer Satisfaction: Degree of stakeholder’s happiness. Scale from 1 (uninterested) to 5 (extremely pleased).
• Customer Dissatisfaction: Degree of stakeholder’s unhappiness. Scale from 1 (hardly matters) to 5 (extremely displeased).
• Priority: Customer’s value.
• Conflicts: Other requirements that can’t be implemented if this one is.
• Supporting Materials: Documents that illustrate the requirement.
• History: Creation, change, deletions, etc.
The formality guide suggests where you need to take more relaxed approach or more systematic with your requirements discovery and communication.
Talking about the different type of project on this chapter, we can find the rabbit, horse and elephant. Rabbit is small, fast and short-lived. This project takes no more than 6 months and lesser number of stakeholders. Horse project is fast, strong and dependable. This project can take from 6 months to 1 year, a dozen of stakeholders is needed and formal documentation too. Elephant project are big, long life and long memory. This type of project must be document, all the steps and details. Involve a lot of stakeholders in different locations.
Quality Gateway:
ReplyDeleteRequirements are the foundation for all that is to follow in the product development cycle. Thus it stands to reason that if the right product is to be built, the requirements must be correct before they are handed over to the builders. To ensure correctness, the quality gateway tests the requirements. By ensuring that the only way for requirements to be made available for the developers is for those requirements to pass through the quality gateway, the project team is in control of the requirements, and not the other way
around.
Reusing requirements:
The requirements can never be unique. The previously done processes can help us if we need to work on any new project as we can find some material of that project to re-use in the new project. Sometimes we can find many requirements that can be reuse without any change. usually we can find requirements that are suitable as the basis for some of the requirements what we want to write in the new project.
Reviewing the requirements:
After completing the requirements specifications, we need to review it to check if there are any missing requirements. Also, that each requirements is being connected to each other fro the representation and no idea is conflicting between any of the requirements. So, in summary, it checks that specification is really complete.
Reviewing requirements
ReplyDeleteThe quality gateway exists to keep bad requirements out of the specification—it does this one requirement at a time. Nevertheless, at the point when you think your requirements specification is complete (or as complete as you need it for the next activity), you should review it. This final review checks that there are no missing requirements, that all the requirements are consistent with one another, and that any conflicts between the requirements have been resolved. In short, the review confirms that the specification is really complete and suitable so that you can move on to the next stage of development. This review also offers you an opportunity to reassess the costs and risks of the project. Now that you have a complete set of requirements, you know a lot more about the product than you did at the project blastoff. In particular, you have a much more precise knowledge of the scope and functionality of the product, so this is a good time to remeasure its size. From that size, and from your knowledge of the project’s constraints and solution architecture, you can estimate the cost to construct the product.