Requirements Management and Communication (BABOK KA)

Natural Language Processing (NLP) is a branch of artificial intelligence that aims to allow machines to comprehend, interpret, and generate human language. It comprises developing algorithms and models capable of processing natural language input such as text, voice, and pictures in order to do activities traditionally performed by humans. Recent developments in machine learning technology, as well as the availability of large natural language datasets, have allowed NLP to make great strides in recent years. Quality checks, extraction, classification of requirements, requirements modeling, traceability of requirements, and retrieval are the six main areas of focus for NLP tools and studies. In this article, I discuss these advances in NLP for requirements engineering (RE). NLP for requirements engineering is a growing field of study, yet there is a disconnect between research findings and practice. This is because there aren’t enough high-quality data sources and domain-specific requirements sources. Despite this, scientific progress has been made in showing potential. The community of practitioners should collaborate with academics and tool suppliers to influence the direction of NPL for RE.

What role can generative artificial intelligence, such as ChatGPT, play in business analysis? Could it interview a stakeholder? How would it deal with a difficult stakeholder? It depends on how well it’s trained.

I set up a scenario with ChatGPT to conduct an interview with a challenging stakeholder. I prepared it with a prompt to prepare for a difficult stakeholder but did not give it any specific objections. A breakdown of the entire prompt follows the interview scenario and transcript below.

Business Capabilities are at the heart of an organization’s planning ecosystem. Capability mapping serves many purposes, two of which are critical. First, business capabilities are instrumental in setting priorities more quickly focusing on the most profitable initiatives first. Second, well crafted detailed capability-based roadmap allows agile project planning that is more accurate, less risky, and takes less time.

Many organizations acquire and adapt purchased packaged solutions (also called commercial off-the-shelf, or COTS, products) to meet their software needs, instead of building new systems from scratch. Software as a service (SaaS), or cloud, solutions are becoming increasingly available to meet software needs as well. Whether you’re using a package as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs. This article describes several ways to approach requirements definition when you plan to acquire a commercial package to meet your needs.

 Here are six more practices that, again, virtually every project will find valuable. These are adapted from our book, Software Requirements Essentials: Core Practices for Successful Business Analysis.

Do you have to do them? Of course not—that’s your choice. The requirements police won’t hunt you down if you don’t. But if you know of any projects that won’t find at least five of them valuable, please let us know. We’ll notify the Guinness World Records people.

There are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.

As an analyst you have to ensure your own understanding of the bigger picture. You have to zoom in and zoom out frequently. You need to analyze either in small initiatives the context under which the ba work will take place. It is possible to get so focused on the solution that your thoughts are stuck only in delivering the solution and forgetting to revisit frequently the alignment with the scope and the context.

A change request (CR) is basically any change in the initial set of signed-off requirements. So, typically in a waterfall model implementation, the requirements phase ensures that all the requirements (features/functionalities/functional and non-functional) are agreed upon and documented before development starts. After that, any new scope brought or requested by clients becomes a change request. There is an additional cost associated with implementing a change request.

Even in the agile model of working, although there is flexibility in the implementation of the project, vendors ensure that a high-level set of requirements are discussed and agreed upon. The iterative way of working ensures that clients have their eyes on the product as it is developing and can suggest corrections or alignments. However, no vendor can work with entirely flexible requirements. It's not feasible from a budgeting standpoint.

Is your requirements approach friendly to vocabulary, policies and messages? I mean directly. Wouldn’t it be of great help to your organization in achieving its goals if they were? In our experience, policy sources almost always need interpretation and disambiguation to achieve an effective practicable form. As this column discusses, the rule message ‘Reserved for Green Car’ provides an excellent case in point.

As a business analyst you will have to communicate internally and externally. Many channels and type of communication may be used. Except ensuring that all the parts have understood correctly the message as you have it in your mind, you need also to perceive what you are saying as important, correct and insightful. You need your communication effort to have impact and many times to trigger specific actions.

Product configuration requirements are a specialized type of requirement when an information system supports product-related needs through data values. Where there are specific changes to business processes needed to sell and/or operate a new product, the requirements for the information system to support activities within those processes involve standard functional requirements.

Whether an information system can support a product though configuration or requires custom development, when an information system is involved there are standard pre-go-live activities that need to be performed (e.g. testing). Requirements support those activities.

Have you ever imagined a situation wherein your vocabulary is missing all of a sudden? What would happen if words weren’t there? Or our vocabulary shrank like ‘Honey I Shrunk the Kids’?

Next to silence, words are a very important part of our conversations :-). When it comes to Business Analysis, there are many challenges around definitions. The project Glossary should contain all key business terms. It is such a straight forward thing but we may assume those things. We may put a little less emphasis on creating a rich project Glossary. Let us zoom in a bit into the common challenges of glossaries and also discuss how to overcome them.

 Not every manager is convinced that his team needs to do a better job on requirements development and management or that such an investment will pay off. Numerous industry studies, however, indicate that requirements issues are a pervasive cause of project distress. Let’s see why investing in better requirements is a smart business decision for any organization.

Business people call remote meetings virtual or on-line sessions, or simply conference calls. For many years we have been utilizing this form of communications to save time and money. Due to the global virus pandemic, remote meetings are now not just convenient, but a necessity for maintaining social distancing. Fortunately we have technology that assists us in managing these remote sessions to not only hear the stakeholders, but see them as well. However, remote stakeholder interviewing and meetings have their additional challenges beyond face-to-face encounters. Regardless of the technology used, we need to be keenly aware of these additional negative risks and pursue mitigations.

Requirements management is a critical function for business analysis. Requirements management is focused on ensuring that the business users and stakeholders have the following information available...  But the more important question to have answer to and where the real business value is delivered in requirements life cycle management is answering the following questions:

1. Are the requirements impacting critical business processes?
2. Which processes have recurring change?
3. Are the requirements priorities aligned to key business processes?
4. Which process will be impacted by which requirements?