Chapter 1- Some fundamental truths - TD Bank

The chapter describes 11 truths, functional and non-functional requirements as well as the Volere Requirements Process. By going into more details about the truths explained:

Truth 1

Requirements are not really about requirements.

Requirements are like a thing which we want and need just like if we need software, we need to build it. If the output product (software) does not fulfill the requirements, it will not be right. One more thing, requirements always exits, whether or not we try to find out those. So, we can say requirements are some kind of natural laws and it is up to us if we want to discover them or no. 

Requirements activity focuses on understanding the business problems and providing a solution rather than just writing a document on requirements. 

Truth 2

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

As the owner is responsible to pay for the development of the software or he is the one who buys the software. If the software is not good enough to meet the requirements, then the owner is the one who pays for the disruption occurring to the business. However, if it works very well, then the owner gets the benefit. So, after considering these things, we can say that the owner buys a benefit.

To be optimally valuable, the product should provide a benefit more than the cost utilized on it. So, the owner must get the benefit as he is spending the money on it to get the benefits.

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 the need is to build the right software. 

 A useful product is what accomplishes the requirements very well. To understand it clearly, we need to know the work of the owner's business and how the work should be done in the future. After considering these points, then the business analysts find out what product is needed to improve the business. Then business analysts produce requirements that describe the function of the product and the quality of the work.

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.

In some cases, software development projects focus on just creating the software. However, this is not always what we need. The software should be valuable to the owner as described earlier, it must solve the business problem as well. Some processes intend to deliver some functions to the users and depicts them that it solves the problems. We build lots of software with the codes of several hundred lines. mostly we get the errors in the output and sometimes the errors are those requirements that we need. So, we need to identify what we need and to build the software which can solve the problem. 

Truth 5

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

It is not necessary to write down the requirements. The more effective way is to discuss the requirements verbally. 

If we write a bulky informative document, describing the requirements in the hope that everyone will read it and work accordingly, it could go wrong as the document might be completely ignored by the developers as it feels boring to read hundreds of lines to find out specifications. So, requirements should be discussed with others verbally. 

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.

Business Analysts can interpret the requirements after listening to the stakeholders' requests that what they need. But, the difficulty can not be understood which is faced by stakeholders while saying trying to describe the needs. So, it is important that Business Analysts record the customer's requests, as well as influence the customers or maybe derive the customer's requirements from the solutions. He should be able to understand that stakeholders can not be trustworthy in case of requirements. 

Truth 7

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

These processes should follow an orderly process which is defined as the set of tasks to achieve the intended result. But the order of the process and applications are to be defined by the team itself. Every process should be done after defined systematic moves.

Truth 8

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

The best approach is to discover the requirements needed in a different direction. The major concern is to discover what is needed without wasting time on producing other documentation. The ways could be different but we need to understand the business problems and the solutions we expect from the product we are developing. 

Truth 9

There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship.

Even using the orderly process, we still need to use our own thinking. Here we need to think about several versions of requirements and the best fit of future products, at the same time. 

Requirements activity needs thoughts and perceptions. As given in the book, "No amount of blindly

following a prescribed practice will produce the same result as a skilled business analyst using his most important tools—the brain, the eyes, and the ears".

Truth 10

Requirements, if they are to be implemented successfully, must be measurable and testable.

To build a product that meets both the functional and non-functional requirements, we must be precise. To maintain that accuracy level, we need to measure the requirements. If the requirements can be measured by using numbers, then it could be tested as well. If we have no measurement for the requirement, then it is not a requirement indeed. 

Truth 11

You, the business analyst, will change the way the user thinks about his problem, either now or later.

When we understand the requirements coming from different stakeholders, then we start to build abstractions and establish a vocabulary. If we have models for the
processes and all the measurements and we can reflect it back to stakeholders, then it will change their thinking regarding the business problem.  

 

chapter 2 The Requirements Process

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 

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.

Chapter 6 Strategy Analysis

Strategic analysis refers to the process of conducting research on a company and its operating environment to formulate a strategy. The definition of strategic analysis may differ from an academic or business perspective, but the process involves several common factors.Strategic analysis is essential if a company has a goal and a mission for themselves. All leading organization who are well known for their achievements have years of strategic planning being implemented at various stages. Strategic planning is a long-term task involving continuous and systematic planning and resource investment. The main question that a company should consider when performing a strategic analysis is: How is the market constituted? How are the active clients in this sector?The Strategy Analysis knowledge area includes the following tasks:
• Analyze Current State: understands the business need and how it relates
to the way the enterprise functions today. Sets a baseline and context for
change.
• Define Future State: defines goals and objectives that will demonstrate
that the business need has been satisfied and defines what parts of the
enterprise need to change in order to meet those goals and objectives.
• Assess Risks: understands the uncertainties around the change, considers
the effect those uncertainties may have on the ability to deliver value
through a change, and recommends actions to address risks where
appropriate.
• Define Change Strategy: performs a gap analysis between current and
future state, assesses options for achieving the future state, and
recommends the highest value approach for reaching the future state

including any transition states that may be required along the way.


Types of strategy analysis :

• Internal strategic analysis
• External strategic analysis

Internal strategy analysis

This analysis organizations look inwards or within the organization and identify the positive and negative points, and establish the set of resources that can be used to improve the company’s image within the market. SWOT analysis is one of the most reputed techniques for internal strategic analysis. There is no better way to benefit from a strategically performed analysis than to use it to detect the strengths, opportunities, weaknesses, and threats that your project may suffer. As we all know better now about the SWOT analysis each one of us has done about our company. Specifically talking about TD bank they care proper care to follow SWOT analysis in the company to do better banking everyday. 

External strategic analysis

Once the organization has successfully completed its internal analysis, the organization needs to know about external factors that can be a hindrance in their growth. To do so, they need to know how the market functions and how consumers react or behave to certain products or services. Measuring customer satisfaction is a common external analysis method.PESTLE analysis (Political, Economic, Social, Legal and Environmental) is used for external strategic analysis. it includes:

Find out the key issues beyond the organization’s control, like changes in political scenario changing rules that can be implemented at any point in time.

Identify the impact of each issue.

See how important these issues are to the organization.

Rate the likelihood of its occurrence.

Briefly consider the implications if the issue did occur.

Requirements Life Cycle Management (Ch 5)

The Requirements Life Cycle Management knowledge area describes the tasks

that business analysts perform in order to manage and maintain requirements

and design information from inception to retirement. These tasks describe

establishing meaningful relationships between related requirements and designs,

assessing changes to requirements and designs when changes are proposed, and

analyzing and gaining consensus on changes.

The purpose of requirements life cycle management is to ensure that business,

stakeholder, and solution requirements and designs are aligned to one another

and that the solution implements them. It involves a level of control over

requirements and over how requirements will be implemented in the actual

solution to be constructed and delivered. It also helps to ensure that business

analysis information is available for future use.

The management of requirements does not end once a solution is implemented.

Throughout the life of a solution, requirements continue to provide value when

they are managed appropriately.

Within the Requirements Life Cycle Management knowledge area, the concept of

a life cycle is separate from a methodology or process used to govern business

analysis work. Life cycle refers to the existence of various phases or states that

requirements pass through as part of any change. Requirements may be in

multiple states at one time.

The most important tasks of Requirements Life Cycle Management are :

• Trace Requirements.

• Maintain Requirements.

• Prioritize Requirements.

• Assess Requirements Changes.

• Approve Requirements.

~Igor Ilin