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:
This final article in the Requirements in Context series discusses detailed requirements for a fully automated business activity. ‘Fully automated’ means that the business information system (BIS) is expected to perform the activity from start to finish without user involvement. A simple example is the system automatically posting a monthly fee against customer accounts. A more complex example is the system utilizing customer-specific pricing details to determine the amount charged for a purchase made by a customer.
First of all, any operating system or solution contains two types of requirements: functional and non-functional. The solution works as a clock, which requires each gear within the solution to be properly functioning. Based on the theory of constraints, any process throughput can only be improved when the constraint or bottleneck is resolved.
Therefore, no matter how fast the train can run and how many passengers it can carry in one trip (the functional requirements), as long as the NFRs are not met, the performance of the solution (subway system) can only be as good as the non-functional requirements.
Second, if NFRs are not considered during the business analysis process, it is very likely they were not part of the criteria for solution evaluation. Without consideration of NFRs, the proposed solution may not be evaluated accurately. What was thought to be the best solution may not be a suitable solution at all.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: