Fundamental Truths

TRUTH 1

Requirements are not really about requirements. 

Requirements exist whether we know them, discover and write them down or not, and are what the software, hardware or service is intended to do. Requirement activity in the business is understanding the problem at hand and finding a solution. 

TRUTH 2
If we must build software, then it must be optimally valuable for its owner. 

The owner is the one that pays for the software and any disruption to the business once the software is deployed. The owner will not buy the software unless the product provides a benefit. The benefits in the business is usually making some business processes faster, cheaper or more convenient. 

TRUTH 3
If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to know what that need is to build the right software. 

You must understand what the product you are building is intended to accomplish by understanding the work of the owner's business. Negotiation must be done with the owner to see which product will improve the work. The kind of work, the kind of product or the methods of the product does not matter to understand the requirements.

TRUTH 4
There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter. 
The software development projects should not solely depend on software's . It is a long process which involves long codes and many errors. Then because of the errors the work is done again and again but still after that we don't know if the user is going to like the result or no. So, providing users with satisfaction and appropriate end product cannot be done by a piece of software. 

TRUTH 5
The requirements do not have to be written, but they have to become known to the builders. 

The way of conveying the information does not matter whether it is written or verbal. In some cases verbal communication is more efficient. However, to improve the understanding about an activities providing requirements is important, written communication should be clear and easy to understand. Additionally, when someone know what they need efforts are made more often.

TRUTH 6
Your customer won’t always give you the right answer. Sometimes it is impossible for the customer to know what is right, and sometimes he just doesn’t know what he needs. 
Sometimes for the customers it is difficult to decide what they need. Same is with the stakeholders sometimes they find it difficult to explain what are they looking for, its the business analyst responsibility to take note of what they say or what they need. So, either its customers or stakeholders the business analyst is the one who has to provide solutions  to any kind of problems and introduce innovative thoughts.

TRUTH 7
Requirements do not come about by chance. There needs to be some kind of orderly process for developing them. 
Requirements do not come by chance. There needs to be some kind of orderly process for developing them.

TRUTH 8
You can be as iterative as you want, but you still need to understand what the business needs.
You can be iterative as iterative you want. but there is still need to understand what the business needs.

TRUTH 9

There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship. 
When Creating a new product or service. There is no one way of creating it. Even though we follow the same standards. That doesn't 100% mean that we're following the correct path. Problems will always occur and gathering and testing requirements are the best way. To see if the constraint can be fixed. All in all, there is no one way of doing things. It's a matter of trial and error.

TRUTH 10
Requirements, if they are to be implemented successfully, must be measurable and testable. 
When creating a product there are aspects that you must consider. For example is it profitable? Furthermore, after you create the product is there any potential increase in revenue? When gathering requirements there are multiple perspectives on getting them. Normally from feedback, getting information from the user if there is a need for change. A precision of information can help see if the product is attractive to the user. Therefore, if the information can be useful and testable. Then the gathered requirements useful.

TRUTH 11
You, the business analyst, will change the way the user thinks about his problem, either now or later. 
Identifying and solving the problem is part of being a Business Analyst. Presenting a business process to help stakeholders understand. If the requirements that they want to have is either attainable or not. A lot of stakeholders out there. Doesn't really know what they want. So, as a business analyst, it's apart of your job to guide them or help them understand the real meaning of requirements.

Why a BA should consider performance requirements?

Performance requirements are written when your product needs to perform some tasks in a given amount of time and to a specific level of accuracy. The following must be considered by a BA while gathering the requirements:

1. Speed- We want things to be done quickly when there is no real need to do so. If a task is to produce a monthly summary report, then there is probably no need to complete this job quickly. By contrast, the very success of the product may depend on speed.

2. Capacity - Capacity is another performance requirement. This requirement is one of the most critical ones for an ATM network.The client for the Ice Breaker product wanted to sell it to road authorities around the world. These authorities are responsible for geographical areas of varying sizes, so the client needed to ensure that the product could handle the largest area covered by any potential client. The appropriate way to define is:

Description: The product shall have the capacity for 5,000 roads.
Rationale: The maximum number of roads in the area of any potential customer for the product.


When you are thinking about performance requirements, consider such aspects as these:
• Speed to complete a task
• Accuracy of the results
• Safety to the operator
• Volumes of data to be held by the product
• Ranges of allowable values
• Throughput, such as the rate of transactions
• Efficiency of resource usage

Requirements

Functional requirements: Functional requirements are those which are related to the technical functionality of the system.

-Formality guide:

Rabbit project:- 

• Have short duration
• Scenarios can be used to make decisions
• Needs detailed requirements

Horse project:- 

• Consistent requirements needed
• precise
• understanding functional requirements

Elephant project:- 

• complete specification
• requirement specification
• Long-term project

-Description and Rationale: So description is like a solution to the problem and rationale makes the need visible in a correct manner to indicate how much attention the requirement should get.

-Exceptions and alternatives: So the unwanted deviations caused due to errors are called exceptions and alternatives are like other options available rather than the one mentioned.

Non-Functional Requirements: It specifies the criteria that can be used to judge the operation of a system in particular condition rather than specific behavior.

-look and feel requirement: this requirement describes the intended mood, style and appearance of the product. A BA must consider the look and feel requirement. Typical look and feel requirement is simple to use, approachable, professional looking, attractive, consistent, innovative and cool.

-Usability and humanity requirement: usability means the ease of using the product or a product that should not be hard to use. In other words to make the product according to the users ability and expectation.

-Performance requirement: this requirement consider these aspects speed, accuracy, volumes, ranges, efficiency.

- Operational and environmental: operational requirement describes that what the product has to do in the environment where it will be used. this requirement cover issues like location of the product, setting for the user, collaborating system.

-Maintainability and support requirement: This requirement should consider organization, laws, business rules, environment, language and culture. It is like a contract to build the product.

-Security requirement: may need a security expert to help deal with protection from threats. Security can thought of having three aspects access, privacy, integrity, data confidentiality.

-Legal requirements: Be aware of any laws that apply to the product. The laws includes consumer protection, guarantee, consumer credit, privacy, freedom of information, data protection.

Tools and Techniques to Generate Requirements

Reusable Requirements

Reusable requirements are documentation or models that can be used for future references. Furthermore, some projects have a similar baseline when tackling each phase. Rather than creating new requirements. We can reuse the old data and saves us time and money.

Prototypes and Sketches

Prototyping and sketches are a well broad-spectrum. Testing multiple requirements is a part of a more detailed process for producing a product. Furthermore, stated in the book, a product can be sketched, and later be reversed, engineer. For a better product

Mind Maps

Mind maps is a diagram used to visually organize information. Normally it shows a relationship between the pieces of the whole idea. It is often created around a single concept and branches out giving information.

Six Thinking Hats

Is a designed system that allows six different perspectives associated with the product. These points of views can be managing, information, emotion, discernment, optimistic response and creativity.

The Murder Book

The murder book is a list of documents. That holds case studies of a previous project. The book may contain information on how a project failed or best practices that can be used. Moreover, the book encapsulates complete information, from the first documentation through the lessons learned.

Difference between Alternatives and Exceptions in Scenario template

Actually, the difference is very easy to explain

 An Exception is anything that leads to NOT achieving the use case’s goal rather unwanted variations in the business use case.

An Alternatives is a step or a sequence of steps that achieves the use case’s goal following different steps which ultimately leads to accomplishment of the goal.

In our IBM event which was more focused on giving information to all the participating stakeholders we discuss about the Cognitive era which was an alternate approach adopted by IBM

Brown cow model

It is a way of reducing the complexity of systems modelling by dividing the model’s viewpoints. For example, the business analyst needs to separate the current view of the system from the future. Additionally, he or she must be able to demonstrate a technological view of the system, along with the technologically-agnostic essential view. 

Brown Cow model gives us the clear view point of the system. Business Analyst will predict the future problems based on the current situation and then will make future business essential policies to improve the current scenario.

Trawling for business requirements

Scope, Stakeholders, Goals

The Scope basically includes the information the people who do it, influence it, or know about it; and the outcome that those people are trying to achieve.Most projects start with scope, but it is not obligatory—you use whatever information is to hand first.

The next part of three-folds is Stakeholders. Stakeholders include anyone with an interest in, or an effect on, the outcome of the product. The owner is the most obvious stakeholder, other than that the consumers of the product are also the stakeholders they have an interest in having a product that does their work correctly.

Then the Goal can be defined as anything that a company desires to achieve rather its monetary or a physical goal. It is also important for the employees of the company so that they know what they need to achieve.

Difference between Sponsor and a customer

Sponsor is the person who pays for the product. On the simple basis that “money talks,” the sponsor, by paying for the development, has the final say in what that product does, how it does it, and how elaborate or how sparse it must be. In other words, the sponsor is the ultimate arbiter of which product will yield the optimal value.

Customer is the person who buys the product once it is ready to use. company needs to produce something valuable for their customers so that they can buy the products for their own use or for others.

Business Use Case

It is basically an external view of the situation. It consists scenarios for discussing the current and future situations of the company with the stakeholders of the company. Also, the case includes the approach used in the project i.e. rabbit, horse or elephant approach. 

Product Use Case

To make the product use case we need to have the business use case first.Because product use case is derived through business use case, so they both are quiet similar. The PUC describes the functionality of the product. The part of the BUC that the customers or the stakeholders agree will be carried forward to make an end product.

.

Scenarios
It is basically a written outline or template of the activities to be performed. A template may include:

• Business event
• BUC name and event
• Trigger
• Preconditions
• Interested stakeholders
• Active stakeholders
• Normal case
• Alternatives
• Exception steps
• Outcome.