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.
It’s important for business analysts to recognize that there is a significant amount of non-technical (i.e. business) detail associated with a system interface capability. The interface is either importing data that’s needed and available in electronic format from another system, or exporting data in electronic format when it’s needed by some other system or organization. The data is either needed in real time or can be processed as a batch job.
For business analysts working in an environment where there is a gap between SMEs and the delivery of an IT-based solution for business needs, requirements are documented to bridge that gap. You are reading this because you are a business analyst responsible for documenting detailed requirements and, in the case of this article, business needs involving one or more user interfaces (UIs) or reports.
The objective of this article is to answer the question, “How much detail is necessary?” Spoiler alert – quite a bit. This is to avoid, as much as possible, a BA having to go back to a SME when designers or developers have business-level questions about a UI or report. Or worse – designers or developers not asking questions. Instead, making assumptions about what the business needs and proceeding to deliver the solution based on those assumptions.
Business rules cover a very broad space. Across the entire space, however, you can be sure about one central idea – business logic should not be buried in procedural programming languages. Call it rule independence. Why is rule independence important to you? Because rules entangled in procedural code won’t ever be agile. Rules change all the time – and in a digital world the pace of change is always accelerating. How you can stay on top of it is the central question in business agility.
Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page. When we talk about a requirements document we are often referring to a Business Requirements Document - or a BRD. But as well as a BRD, there are 9 other types of requirements documents that a business may want to use while pushing a project through its stages of completion. The type of format to be used depends on the result of the project itself, whether it’s a product, service or system, and the particular requirements it has.
If someone said you could only perform a single quality practice on a software project, what would you choose? I’d pick peer reviews of requirements, which I believe are the highest-leverage quality practice we have available today. In a peer review, someone other than the author of a work product examines the product for quality problems and improvement opportunities. Reviewing requirements is a powerful technique. Use them to identify ambiguous or unverifiable requirements, find requirements that aren’t sufficiently detailed yet, spot conflicts between requirements, and reveal numerous other problems.
Reuse is an eternal grail for those who seek increased software productivity. Reusing requirements can increase productivity, improve quality, and lead to greater consistency between related systems.
Reuse is not free, though. It presents its own risks, both with regard to reusing existing items and to creating items with good reuse potential. It might take more effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project. In this article we describe some approaches an organization could take to maximize the reuse potential of its requirements.
The objective of this article is to provide business analysts with guidelines for distinguishing between high-level requirements (HLRs) and detail requirements (in IIBA® BABOK® V3 terms – Stakeholder requirements and Solution requirements respectively).
In this article, I want to share my knowledge on how to manage product backlog using Jira. The article will be useful not only to business analysts or product owners but also to scrum masters, project managers. Basically, anyone who works with backlog and requirements on a project will benefit from reading it. There are certain rules and approaches that you have to follow to achieve good results.
Before we take a look at it I want to point out that this approach is not a market standard yet. However, over the last 3 years, I’ve completed a good number of projects using the approach I’ll be describing here
On the image below I tried to emphasize the main activities and processes that should be presented in your project. You also have to keep in mind that each artifact and process has own goal and definition.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: