The Rationale for the Rationale:

The Rationale is the reason, or explanation for a requirement. The rationale is very useful to add with requirements because it helps the reader to understand the proper need of that requirement. Rationale gives the proper guidance on the importance of the requirement to the developer and to the tester. Rationale is also known as helpful for the future related activities as well as it separates the different requirements. To find the proper criteria there is a need to be start by finding the description, and rationale which made for requirements.

Deriving Fit Criteria:

Fit criteria is very important for the requirements. It tells about the requirements that are subjective and ambiguous. Some fit criterion need adjusting at some of the points as they are unattainable due to financial or other constraints. It have some measurements for different kind of requirements.

By: Kirandeep Kaur Gill

Source:
Robertson, S., & Robertson, J. (2014). Mastering the Requirements Process (3rd ed.). Upper Saddle River, N.J: Addison-Wesley.

The Non- functional Requirements Types

The non-functional requirements are grouped into the eight non-functional requirements types as explained

Look and feel: According to this requirement the appearance of the product is important for both the user and the provider of the product.

Usability and Humanity: This explained that the product should be easy to use and there should be more importance for the product fell to make it more worth in giving the better results to the user of the product.

Performance: It tell us the product should have the right pace for the user to use as it includes everything as started from who much your product is safe to use, Is your product is fast and has accurate functions in it to provide the user a good experience in usage.

By: Sachin Chopra

Source:
Robertson, S., & Robertson, J. (2014). Mastering the Requirements Process (3rd ed.). Upper Saddle River, N.J: Addison-Wesley

Description and Rationale:

Why is this aspect of requirements development important? Because it is far too easy to hide important functionality by describing an implementation, and far too easy to select the most obvious implementation when better ones may exist. Regardless of how the need is finally implemented, it is clear that writing both the description and the rationale leads to discovery of the real requirement.

Avoiding Amiguity:

Whether the sources of your requirements consist of written documents or verbal statements from interviews, you should be aware of the enormous potential for ambiguity and the misunderstanding that ambiguity can cause.

Technological Requirements:

The technological requirements are not there for business reasons, but rather to make the chosen implementation work. It is suggested that these requirements either be recorded in a separate specification or be identified clearly as technological requirements and recorded along with the business requirements.

Created by: Haoyan Yin

Citation:

Robertson, S., & Robertson, J. (2014). Mastering the Requirements Process (3rd ed.). Upper Saddle River, N.J: Addison-Wesley

The Essence of the Business:

The essence is described as not a better solution to the problem, it identifies the real problem without technology. When creating and looking at scenarios identifying and breaking down these concepts allows a Business Analyst to define Business Events, Business user cases, triggers, preconditions, interested stakeholders, active stakeholders, normal/ alternative options with sxception steps, and finally the outcome.

Personas:

These are invented personalities that business analysts will create that represent similar users. This is a useful tool when there are many stakeholders who aren’t readily available to interview. These detailed profiles of fictional characters which represents specific segments of users within a targeted demographic help gather additional information for market segmentation.

Adjacent Systems & External Technology:

Business Analysts use these systems and play an important role to help understanding scope of the product being built. Active systems refer to people who interact with the work while autonomous are computer or people who don’t directly interact, but still have one-way day flows with the work. Lastly, Cooperative systems refers usually to the computer systems acting as part of the work.

Created By: Mark Stabile

Trawling the business Requirements:

It is defined as a logically examining concluded a business to recognize the work being complete. In other words trawling also stands for a big net that use to catch fishes but it is also searching through find something.

Formality Guide:

1. Rabbit Projects: It is one of the formality guide for business projects. It is all about to visit the current work of projects divide into small pieces and then continue to find its core and eventually its explanation. It is done with few stakeholders also need less documentation. More important the cycle is repeated until the project is complete and project take short period of time.
2. Horse Projects: It is another formality guide for business project. Horse projects are large number of projects and long time projects. It includes large number of stakeholders and possibly make more widespread use of apprenticing, interviewing, and use case workshops. It also include the documentation for current work for projects.
3. Elephant Projects: Elephant projects are known as larger projects. Elephant projects done with more stakeholders than other projects and it require more documentation on ongoing basis with formal specification that develop projects.

The Brown Cow Model:

It is a business use case model mainly has four views of work and differently two axes are separate What from How, and the Now from the Future. Lower left sides of the model is for How – Now. It focuses on the application of the work as it currently happens, including the physical objects, and workstations used to do the work.

The upper left side is about the What – Now it tells about the real business policy, and for essence of the work. It also focuses on the ideas of current business is actually doing. The upper right side is all about the Future – What view. It look for the future state of business area also about the enhanced business policy models and for innovations.
The last one lower right side focuses on the Future – How. It tells about the ideas that use for future business policy, technology, and people that bring ideas into real world. Future – How includes new workflows, new design models, and new roles.

By: Kirandeep Kaur Gill

This chapter will introduce the Volere Requirements Process and its associated specification template from the activities and deliverables that had proved to be effective in a project. It will help you to discover and communicate your requirements more productively and accurately. The whole process is shown in the image and some of them are used more frequently and have greater influence:

Project Blastoff:

The main 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. It defines the business scope and acts for reference from the stakeholders.

Trawling for Requirements:

Basically means discovering the requirements. Business analysts will discuss the current situation and future hope with the technicians as well as consulting the stakeholders for their expectations.

Iterative and Incremental Processes:

This method is used with iterative development life cycle, in which, after a preliminary analysis, the product is developed in small increments to provide the most agile way to meet the needs of stakeholders.

Created by: Haoyan Yin

Citation:

Robertson, S., & Robertson, J. (2014). Mastering the Requirements Process (3rd ed.). Upper Saddle River, N.J: Addison-Wesley

There are many truths that Business Analysts must face when dealing with business requirement gatherings. These truths help one understand their roles, duties, and responsibilities as discussed throughout our blog. Our textbook addresses 11 truths that if not followed will lead to project failure, so understanding each is crucial if one wants to be a successful Business Analyst. All 11 truths are important, but I will discuss a few truths that stuck out to me that I would like to bring forth that include:

Truth 2: Optimal Value:

 Cost/benefit analysis must be conducted to see if what you are doing outweighs the costs (which is a combination of time and money). The question “Is the really worth it?” gets addressed and answered by Business Analysts as they figure the best optimal/maximum ROI for the project.

Truth 9: There is no Silver Bullet (methods and tools will not compensate for lack thought and poor workmanship.

You may have all the tools and materials to help you, but don’t rely on it to do the thinking for you. You still need innovation and critical thinking skills to get to your final product.

Truth 10: Requirements need to be measurable and testable.

To achieve the necessary level of precision a Business Analyst needs, one must somehow measure a requirement. If you can measure the requirement using numbers instead of words, you can make the requirement testable and therefore provide validity to your project.

Created by: Mark Stabile

Citation:

Robertson, S., & Robertson, J. (2014). Mastering the Requirements Process (3rd ed.). Upper Saddle River, N.J: Addison-Wesley

Requirements in the Life Cycle Managements have some of the important task to perform in the organization.

I am going to talk about the important requirements in the life cycle process

Trace Requirements – This the all about establishing the imperative relationship between the important elements in the organization which effects business in both positive and negative manner. the requirements, the design of the product, other elements for the oriented results of the findings

Maintain Requirements – The important ideas and the imperative designs have be done to check the accuracy and should made the changes in the process required

Prioritize Requirements – There is always a way to make the work done in with the best approach as the important element as the things can be done with the urgency of the work and the other required results from the work in the particular time and need to manage the work as needed.

Access Requirements Changes– The stakeholder are the imperative part of the organization on which the business is dependent on to make the necessary adjustments to make the stakeholders interest in the company

Approve Requirements – The approval of the business stakeholders is important task to make the work done with the efficiency and effectiveness

Sources : LIBA. (2015).Guide to the business analysis body of knowledge: BABOK guide. Toronto: Ontario.

By: Sachin Chopra