BR Chapter 2: Key Areas



Projects that lack a clear understanding of the business and customer requirements often suffer from re-work, delayed schedules and/or cost overruns. The Business Analyst must be able to provide the project team with clear customer
 requirements for the product, service or system that the project will deliver. And these requirements must translate into measurable business requirements and project deliverable. 

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements.
Below are some of the key area worth understanding in the requirements process:



11.     Project Blastoff
This is where we establish a solid foundation for the requirements and ensure that the members of the project team all start rowing in the same direction. The key purpose of the project blastoff is to build the foundation for the requirements discovery that is to follow, and to ensure that all the needed components for a successful project are in place. The principal stakeholders - the sponsor, the key users, the lead requirements analyst, technical and business experts, and other people who are crucial to the success of the project - gather together to arrive at a consensus on the crucial project issues.
The Project Blastoff is a burst of activity to launch a requirements project. It assembles enough information to get your project off to a flying start and to ensure it is viable and well founded. A blastoff might last a few hours or several days—it all depends on the size of the project and the amount of uncertainty.



22.     Quick & Dirty Modeling
This expression refers to completing a task rapidly rather than making it high quality. Usually, things that are quick and dirty serve a temporary purpose rather than long term. The models can be used at any time in the Volere life cycle and the activity can be regarded as “Prototype the Work.” 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.
A quick and dirty prototype built on a whiteboard to provide a rapid visual explanation of how some of the requirements might be implemented, and to clarify misunderstood or missing requirements. One notable advantage of this technique is that stakeholders tends to relate to this way of  modeling their business processes and are always willing to participate with hands-on manipulation of the Post-its to show what they think the work should 



33.     Quality Gateway
The Quality Gateway is a gateway into the requirements specification. That is, each requirement must be tested by the gateway before it may be included in the specification with the other correct requirements - we prevent unworthy requirements becoming part of the specification. Consider the life of a requirement before it arrives at the Quality Gateway. The requirement could have originated anywhere or with anyone. Variety of trawling techniques are used to discover the requirements. Each requirement is captured regardless of its completeness or coherency - whenever and however it appears.
The quality gateway ensures that requirements are rigorous by testing each one for completeness, correctness, measurability, absence of ambiguity, and several other attributes, before allowing the requirement to be passed to the developers.



14.     Formality Guide
The Formality Guide provides a technique where the Business Analyst can take a more relaxed approach to recording requirements. Below terms are some of the major conventions used in the formality guide for requirements process.

RABBIT PROJECTS
Rabbit projects are small in nature, fast, and short-lived. These kinds of projects are typically smaller projects with shorter lifetimes, where close stakeholder participation is possible.
Rabbit projects should have sketch of the work scope diagram pinned to the wall close to their user stories; closed by should be a list of stakeholders. Finally, written with a broad marker pen on the wall, are the project goals. Rabbits will probably have only a brief blastoff meeting at best, with most of the consensus on the blastoff meeting coming from phone calls, and other informal interactive means.


HORSE PROJECTS
Horse projects are the most popular and most common. They are fast, strong, and dependable. Horse projects are probably the most common corporate projects - they are the “halfway house” of formality.
Horse projects should be more formal and hold a blastoff meeting, and they should also record their deliverable and communicate them to the appropriate stakeholders. Horse project might benefit from producing first-cut sketch of the guessed-at product to ensure all stakeholders understand where the project is headed.

ELEPHANT PROJECTS
Elephant projects are seen by most people as the "Mover and Shakers" projects. They are super solid, strong, with longer life, and a longer memory. An elephant project has a need for a complete requirements specification.
Elephant projects have a lot to lose by not having the blastoff deliverable firmly in place before proceeding further in the product development process. In most cases the deliverable are discovered during the meetings with the key stakeholders and the results are recorded and distributed. Elephant project must take the additional steps of having quality assurance people (QA) test their blastoff deliverable - because they are critical and costly if they make errors.

15.     Requirements Retrospective
Retrospectives are used frequently to give teams the opportunity to pause and reflect on how things have been going and then, based on those reflections, identify the improvements they want to make.
Conducting Retrospectives frequently and regularly supports a team to continuously improve their performance. Retrospectives for requirements projects consist of a series of interviews with stakeholders and group sessions with the developers and the intention is to canvas all the people involved in the process and ask tough questions:

    • What did we do right?
    • What did we do wrong?
    • If we had to do it again, what would you do differently?

Then, based on the answers, the team will decide on actions to improve the process in the future - the fundamental idea is very simple: Do more of what works and less of what doesn’t.
The most notable feature of retrospectives its consistently and significantly improvements in processes. Retrospectives are probably the cheapest investment you can make in your own process.




Source:
Mastering the Requirements Process: Getting Requirements Right
Suzanne Robertson, James Robertson
https://www.batimes.com/articles/the-requirements-process.html

Comments

  1. Yogesh JaglanNovember 12, 2019 at 9:07 PM

    Quick and Dirty Modeling:
    Models can be utilized whenever in the Volere life cycle; we appear this movement as "Model the Work." There are, obviously, formal models for example, you would discover in UML or BPMN, however a great deal of the time business examiners can utilize snappy portrays and graphs to demonstrate the work being researched. One no fuss displaying method we
    should make reference to here is utilizing Post-it notes to display usefulness; each note
    can be utilized to speak to a movement, and the notes can be quickly modified
    to show various ways the work is done or should be possible. We find that partners identify with along these lines of displaying their business forms, and are continually ready to take an interest with hands-on control of the Post-its to show what they figure the work ought to be. We inspect how you move into an usage of the necessities found up until now. Now, your models change from being something to clarify the present work, to something to clarify how the future item will help with that work. We would now be able to begin to allude to this sort of model as a model—a fast furthermore, filthy portrayal of a potential item utilizing pencil and paper, whiteboards, or some other commonplace methods Prototypes utilized at this stage are planned to give the client a recreation of the prerequisites as they may be executed. The Icebreaker business investigators sketch some proposed interfaces and ways that the required usefulness may be actualized—this visual method for working permits the specialists what's more, different partners to coalesce their thoughts for the future item

    ReplyDelete
  2. Amanjot kaur chahalNovember 25, 2019 at 10:06 PM

    Part of a business’ growth is the deployment of separate departments which functions with specific focus and definitive path. They are structured according to certain business requirements and these departments will vary depending on the type of business being practiced. Knowing the different functional areas of a business is a basic but major necessity for an entrepreneur especially when he’s still in the planning stage.
    In order to achieve the company’s goals and objectives, the company’s Human Resource Department is responsible in recruiting the right people with the required skills, qualifications and experience. They’re responsible for determining the salary and wages of different job positions in the company. They’re also involved in training employees for their development. It’s vital for business that the products are in good quality and free from defects. The production department is concerned with manufacturing the products, where inputs (raw materials) are converted into finished output through a series of production process.

    ReplyDelete
  3. Dalsher Singh VirkNovember 30, 2019 at 4:47 PM

    I believe that having a Formality Guide is very important for every project. There is every reason to make your requirements discovery and communication as informal as possible. We say “as possible” because it is not so much what you would like as what your situation demands—often the degree of formality will be dictated by factors beyond your control. For example, you may be developing software using contracted outsourced development. In this case, there is a clear need for a complete written requirements specification.In other cases, the way you communicate your requirements can be informal to the point that a portion of the requirements are not written, or partially written, and communicated verbally.

    ReplyDelete

Post a Comment

Popular posts from this blog

BR Chapter 12: Fit Criteria and Rationale

A satisfying viewpoint (among a large number) of Kent Beck's eXtreme Programming system is its emphasis on composing experiments before composing the code. The experiment characterizes the measuring stick that the executed code must match. The fit model is pretty much something very similar: It is a measuring stick for the necessity. By adding a fit rule to the necessity, you are, basically, composing its experiment. In the event that you are utilizing client stories, at that point we firmly propose that you give specific consideration to the explanation given for the usefulness. This is pretty much equivalent to the justification, and is a significant supporter of winding up with the right item. Composing experiments on the back of the story card ought to accomplish a similar reason as the fit standard we talk about here.  For each of the non-practical necessities yielded by the blog, we presently propose determining the fitting fit rule, affirming it with the partner, and compo...
Read more

BA Chapter 9: Underlying Competencies

Image
Underlying Competencies are a description of the behaviours, characteristics, knowledge, and personal qualities that support the practice of business analysis. BABOK® defines 6 key groups of competencies that a BA is expected to possess. Each competency group constitutes of multiple sub competencies which are as discussed below: (Source: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1287/Developing-a-Competency-Model-for-Business-Analysts.aspx) 1.      Analytical Thinking and Problem Solving : These skills are required for business analysts to analyze problems and opportunities effectively, identify which changes may deliver the most value, and work with stakeholders to understand the impact of those changes. Analytical Thinking and Problem-Solving core competencies include: ·            Creative Thinking ·           Decision Making ·  ...
Read more

BR Chapter 6: Scenarios

Image
At this stage of the requirements process, the business analyst has identified the business events as well as the business use case which we referred to as BUC and these correspond to the business events.   Below are some of the techniques the Business Analyst can use to communicate requirements to the stakeholders: Scenarios The Business Analyst can use Scenarios to model and record the BUCs. A scenario is an outline of a plot, or a postulated sequence of steps - it tells the story of a business use case.   The scenario is a neutral medium, and one that is both simple and understandable to all stakeholders.  A business analyst would use a scenario like this to elicit, and then describe, a business use case to its interested stakeholders. The BUC is a discrete amount of functionality; it happens in its own time frame and can be considered separately from other parts of the work’s functionality. The BA model a scenario and use it to reach a...
Read more