All the things you need to know in Software Requirement gathering
1. Understand the problem before converging on a solution
Instead of just assuming that you have the right problem and an appropriate solutio in mind, Need to do some root cause analysis first. In Here to clarify the requirment BA define the 5 why questions?
- Why is that a problem?”
- “Why are we not already achieving that goal today?” etc.
BA would repeatedly ask until you unveil the compelling issue. Thats we call 5 why questions. While asking the why questions we can draw root cause analysis or fish born diagram like below. You can get from a presented problem to the root cause that contribute to it. Then you can derive a good solution with confidence that it will address the real problem.
2. Define business objectives
Lets say someone new join your team. Maybe they ask questions to better understand the business context from your project and what team is hoping to accomplish.
- What business problem are you trying to solvce
- what is the motivation for solving this problem
- what would a successful solution do for you
- How would the product provide value to the company or its customers
- How could you judge the solutions success
- How will you know you are done
If you can answer these type of questions congrats you have successfully define the business objectives. Shared understanding of business objectives keeps everyone aligned toward common goal.
3. Define the solution boundaries
When you start on working the project, you might not known exactly where to draw the line between what the solution should and should not include.
- Which business processes, functions and events will be part of the solution
- Who will use or derive benefits from the solution, who is excluded (stakeholders)
- Which software systems will be part of the solution
- Where do each systems responsibilities begins and end
- How does our solution fit into the rest of our universe
By getting answers to the above questions, you would able to clearly identify where the solutions ends and its boundaries. These details can be shown using context diagram and ecosystem map. These contributes to scope definition, product roadmap definition and release planing.
4. Identify and characterise stakeholders
Every project has its stakeholders, individuals or groups who are actively involved in a project, or affected by it, or can influence its direction. Some are in the development team, some are in developiong organization and others are outside the developing organization.
- Who has influence or control over the projects budget and schedule
- Who can articulate the projects business objectives
- Who will be using the product directly or indirectly
- Who could have legal, compliance, regulatory or process influence
- Whose business process would the system affect
- Who would know about any pertinent constraints
Overlooking stakeholders can lead to requirment gaps or unknown constraints that are disruptive when they are finally discovered.
5. Identify empowered decision makers
When you start working on a project you have to face continous stream of decisions. These are some of the decision you have to take in requirment gathering.
- Resolving conflicting requirments within and across user classes.
- Prioritizing requirments of various types
- Resolving conflicting priorities among stakeholders
- Adjusting priorities as reality happens
- Defining the scope of each development increment
- Determining which new or changed requirments to incoporate
Each group should identify the decision makers regarding requirment related decisions. They should agree and come to conclusion. That is what decision rules the follow. You can have a vote scenario or do they reach consensus. THe decision making in requirments is a critical step, so we need to identify who is the correct person to make the decision. In agile practise most time client will be the one who take the decisions.
6. Understand what users need to do with the solution
When you are working requirement elicitation(gathering) with users, you might ask “What are your requirments”, “What you want the system to do”. But it is not good to ask from the user. Client is focusing on the product and its features not on the users. In this phase Use cases or User stories comes for the help.
Discussion with stakeholders and further analyses leads to gathering necessary functional requirments and relevant tests. Those discussions also reveal business rules that appropriate to the usage scenarios and stakeholders expectation and quality attributes.
All these information you gather will feed into defining accurate solution.
7. Identify events and responses
Use cases or User stories plays major roles in interactive systems. But you may face projects involve with the systems that dont have user interaction. Real time and middleware products are more effectively analyzed using events and responses.
Business Events : Originates from the outside world. Business offten are use cases.
Signal events : Originates from a hardware device like a switch or sensor or arrives like messages from communication channel.
Temporal or time-triggered events : This stimulate system to perform some action either at specified time or after some duration has passed.
For signal events and temporal events you can draw a table or diagram that shows possible events and the expected system responses. This would help for test planing also.
8. Assess data concepts and relationship
All software applications create, update or delete data. So Data plays major role in system. You need to identify what type of data the system goes with.
- What data does each solution component require?, Where does it come from?
- What data does each component produce?
- What are the internal and external data flows?
- What business rules apply to each data objects
- What information must be input or display on user interface screen
- What are the policies for data quality, security, intergrity, retention, archiving and disposal
When you understand the data, you need to identify the relation among them. You can create entity relationship diagrams. From this we can get data interconnections. You can create a data dictionary to contain the details for developers need for implementation. Data exploration is a major aspect of requirement development.
9. Elicit and evaluate quality attributes
When discussing with users, users naturally focus on the functionality they want to see in solution. But sometime we use application to do something, but we dont like it. In that system it have the right functionality but it is poor in quality.
You need to work with stakeholders to find out which quality attributes suitable for your system. This would help designers to make appropriate decisions.
10 . Analyze requirements and requirement sets
After requirment elicitation, Requirment gathering is the BA really valued. We can use several specific analysis techniques to produce better requirements and better products.
Origin and rationale. You should be able to trace each requirement or user story back to its origin, which could be a stakeholder request, use case, policy, quality attribute, or some other source that led to including it. If anyone asks why a particular requirement is present, the BA should have a compelling answer. Understanding the rationale for including each requirement helps people make priority and scoping decisions based on the requirement’s value to stakeholders.
Decomposition and derivation. A big portion of analysis is to decompose large or high-level requirements into enough detail that they are well understood. Finding the right level of granularity is tricky. There’s no point in overly detailing requirements prematurely, particularly if they’re likely to change or be dropped. However, you need a certain amount of information to assess each requirement’s priority and feasibility, more detail to estimate their size and implementation cost, and still more to know exactly what to build.
Exceptions. People naturally focus on describing how they expect the product to behave when everything goes well. However, developers write a lot of code to handle exceptions that could prevent successful execution. During analysis, identify potential error conditions — user actions, system conditions, or data values — that the system must detect and handle to minimize their adverse impacts.
Quality assessment. Experienced BAs automatically scan for certain characteristics as they review requirements. A statement that lacks any of the following properties demands further exploration and improvement
- Complete. No necessary information is missing.
- Correct. The requirement accurately states a stakeholder’s need or a necessary property of the solution.
- Feasible. The requirement can be implemented within known technical, business, and project constraints.
- Necessary. The statement documents something a stakeholder really needs.
- Prioritized. The requirement is ranked relative to others as to its importance and urgency of inclusion in the solution.
- Unambiguous. The statement conveys only one possible meaning to all readers. This is particularly important — and challenging — when team members have different native languages, where wording subtleties can cause confusion.
- Verifiable. There’s some way to demonstrate that the requirement has been correctly implemented.
Acceptance criteria. Consider how someone could judge whether the requirement was correctly implemented and ready for use. Acceptance criteria can describe system behaviours, tests, performance measurements, or anything else that shows that the requirement is satisfied. Agile teams typically document acceptance criteria to flesh out the details of user stories, including exceptions. That is, they derive acceptance criteria or tests rather than refining a story into detailed functional descriptions.
Assumptions. An assumption is a statement that people regard as being true without definitive knowledge that it is true. People often make unstated assumptions regarding requirements. Conflicting and obsolete assumptions can cause problems later. One user might assume that a particular business process will be automated in the new system; someone else assumes that it will not. Try to make any requirements assumptions visible and validate them to convert those assumptions into facts.
Constraints. Constraints restrict the developer’s design or implementation options. Common sources of solution constraints include business rules, compatibility with other systems, physical realities (such as size, interfaces, and materials), data and interface standards, and quality attributes. Project constraints include limits on budget, time, staff, and skills. Some requirements writers inadvertently impose constraints by including user interface or other implementation-specific language. Confirm whether those truly are restrictions (“It must be done like this for a good reason”) or just solution ideas that someone proposed (“Here’s an example of what I have in mind”).
Business rules. Business rules often influence, or serve as the source of, specific pieces of functionality or data. It’s important to know which business rules apply to which processes, functions, and data objects.
Hazards and risks. Software-containing products that pose safety risks must include hazard analysis as part of their requirements analysis activities. Requirements analysis should also consider risks that could arise from each requirement, including these
- Performance impact on the system
- Security threats
- Business process impacts
- High complexity or novelty that could make the requirements hard to understand
- New development techniques or technologies needed
- Risks that specific requirements may pose to business strategies, enterprise architectures, legal and environmental factors, and the like
- Adverse interactions with other systems, components, or databases
Reuse potential. Requirements reuse involves both crafting requirements that can be reused in other contexts and finding existing functionality that your application could exploit. Consider both reuse aspects during requirements analysis. If a process or a set of requirements is likely to be repeated, consider creating a generalised template for those requirements to enhance reuse. Once had a project that involved multiple file-based vendor integrations. The transport of those files to the respective vendors was essentially identical; only the file locations and encryption keys would differ. The team created a template for the vendor integrations that every business area could use to insert their own vendor’s name, location, and encryption key without having to replicate the functional requirements.
When analyzing set of requirements
Gaps. When you examine a set of requirements, it’s hard to see the ones that aren’t there — they’re invisible. Finding missing requirements involves reading between the lines. To assess completeness, trace downward from business objectives through user requirements and into solution requirements to ensure that they all align properly. Common sources of omissions include stakeholders who haven’t provided input, missing exceptions, situations involving complex logic in which some combination was missed, and overlooked data. Requirements models provide a powerful tool for identifying gaps, as visual representation techniques make omissions far more obvious than textual representations can.
Conflicts and inconsistencies. Inconsistencies can arise between a parent requirement and its children. Requirements of the same type also can conflict. One says to do A and another says to do B, but it’s logically impossible to do both. When developing iteratively, ensure that new requirement sets don’t conflict with what has already been built without good reason and that new functionality won’t break what is already there.
Overlaps and duplications. Look for multiple instances of the same information. Karl once reviewed several use cases that had nearly — but not exactly — the same data structure definition in three places. The reader doesn’t know which one to believe, if any. Replicating information does make it easier for the reader, who sees the whole package of related information. However, replication raises the risk of generating an inconsistency if one instance is changed but others are not. When possible, point to a single, reliable source of the information rather than repeating it.
Dependencies. Some requirements depend on others being implemented at the same time or previously. For instance, it only makes sense to implement exception-handling code concurrently with the functionality where the error could occur. If you’re enhancing a feature over time by gradually adding more capability, plan implementation so that each new sub-feature builds on the previously laid foundation. A requirement also could depend on a certain feature being enabled or modified in a product to which it interfaces.
Quality assessment. Beyond the desirable characteristics of completeness and consistency discussed above, look for these other good properties in requirement groups.
Modifiable. The collected requirements are organized and labeled in a way that makes it easy to change them and to keep records of the changes made.
Traceable. It’s possible to document logical links from requirements back to their origins, to related requirements, and to other development products like designs, code, and tests. Traceability depends on requirements having been written at a fine level of granularity and uniquely labeled.
Representation in different forms. There are many ways to depict requirements knowledge beyond natural-language text. Creating more than one representation using different thought processes lets you compare them to find problems. Excellent ways to find requirement problems are to create diagrams or tables to accompany the text and to build prototypes. Such alternative views of the requirements also facilitate clear communication with developers and other team members.
Prioritization. No team can simultaneously implement everything in its backlog of pending work. Negotiating requirement priorities lets the decision makers sequence the work in a way that is technically sound and delivers the maximum, most timely customer value.
Assumed and implied requirements. Stakeholders sometimes assume that the solution will include certain functionality without them having to say so explicitly. Those assumptions can lead to disappointments; telepathy and clairvoyance are not effective requirements tools. The presence of certain functionality sometimes implies that other functionality is needed, again without explicitly calling it out. For example, an undo function implies a redo function. Decomposing a high-level requirement into a set of lower-level requirements to fully understand its complexity is one way to discover those implications and manage expectations.
By finding requirement errors you can avoid potential rework by casting errors in code.
11. Create requirement models
Stories are not always the best way to represent requirment knowledge. This might loose you in the jungle of requirments and you miss the big picture and overlooking errors.
Benefits:
- Various diagrams present multiple views of knowledge, processes, data, states and context.
- Models present information at higher level of abstraction than textual details
- Models facilitate rapid iteration
- Modeling rule violations reveal omissions and errors
- Conflicting diagrams reveal incorrect, missing or unnecessary requirements
Common models
Requirement modeling is powerful analysis tool. Creating alternative requirements views through different thought processes is a good way to discover problems that could lead to incorrect conclusions.
12. Create and evaluate prototypes
Some times user may strugle when he describe the user stories. But he will identify easily if he sees it. Thats when prototypes comes to the scene. Mostly people find it easier to critisize some thing before them than describing it.
13. Prioritise the requirements
Once you gather all the requirements, you would find out all of them cannot fit into the box. which is bounded by time, budget and resources. So you need to find the most priority requirments.
Requirement prioritizing factors
- The customer or business value requirment would deliver
- The contribution to the project or iterantion’s goal
- Who requested it
- How frequently it would use
- The cost, time and difficulty of implementing it
- Time sensitivity
- Dependencies with other requirments
- Its necessity for legal, regulatory or safety reasons
At last you are not likely implement requirment that every stakeholder would like, use prioritize to make sure you implement the right feature first to maximize the deliver customer value.
14. Write requirements in consistent ways
When documenting requirments there are many ways to requirment information.
Here are some commonly used patterns for describing solution functionality
- Functional requirement pattern : user perspective (Owner shall be able to change the security systems passcode)
- Functional requirement pattern : System perspective (Security system shall allow the home owner to change the passcode)
- User story pattern (As a home owner I want to change my security passcode so that i can prevent the use of previous owners passcode)
The key is to choose the representation that will communicate each piece of information efficiently and accurately.
15. Organizing requirments in a structured fashion
Now you would have sketches, requirements, prototypes, oops its huge of files what we are going to do with these all. In this phase Organizing the requirment in structured pattern comes to your help
Different containers for different types of requirements :
- Business req : Vision and scope document
- User req : User requirment document
- Solution req : Software requirment specification
Different storage mechanisms:
- Document, spreadsheet, database, requirments management tool, note cards, sticky notes etc
Follow a template
- Organize information consitently to spot gaps in your requirment knowledge
Adopting to store requirment information in a better way makes your life easier.
16. Identify and document business rules
Sometimes you may think why we need to know about the business rules. Here are why we need to know about them
- Business rules are statements that define or restrict organisations operations
- It may be influence behaviors of people and software systems, within the organization.
- Business rules are not requirments in themselves, but functional data requirments are derived to make system comply with those rules
Types of rules
Business rules may ciome from various sources, including company policies, laws, regulations and industry standards
17. Create a glossary
When you gather requirments you may face users may different words for same thing or used the same term to mean different things.
When creating the grossay you need to find
- Definition of terms, abbreviations, acronyms, synonyms
- Use terms consistently within a project
- Distinguish domain-specific meanings from their usage in other contexts.
- Some terms can have multiple meanings within application context
Glossary helps to communicate clearly and effectively about requirment information. Enterprise level glossary can provide consistency across applications.
18. Review and test the requirements
Lets say you have requirments. You have still confusion are they are the right requirments. How can I know the correctness of these requirements.
Here are some techniques you would do :
- Peer review of documented requirements : include user representatives, marketing team, author of higher level specification and subject matter experts. Use more formal, rigorous review for higher risk set of requirements Use a checklist of common requirment errors
- Writing tests against requirments : This gives full understanding of how it works. Compare requirments against test, you would identify both errors. You can use test to walk through models and establish a consistent shared, requirment understanding.
These validating techniques can reveal requirment errors mmuch faster , cheaper and earlier.
19. Establish and manage requirement baselines
After gather requirments at some point team need to identify what requirements they are going to pick and can commit to implementing.
Baseline : An agreed upon set of requirments for specific development cycle.
- Time bound baseline : Begins by establishing a time box like a release. Team allocate requirments from their backlog until the time boxes capacity is filled.
- Scope bound baseline : This is set of requirments that can be build , tested and deployed together as a unit. This established without necessarily knowing its size or delivery schedule.
Baseline is the reference point against which changes are requested including contingency buffers provide you accommodate some change with minimal disruption.
So requirement baseline is merely an agreement about what will be built and when. Your project would run smoothly with clearly defined agreements and commitments.
20 Manage changes to requirements effectively
Once you give the working product to the user. User definitely come back with can you change this to that and etc. So changes are expected of software project. Team need to have structures to deal with requested changes.
- Define a change control process
- Follow it for all request changes
- Identify the decision makers
- Assess the impact of each requirement change
- Update requirment baseline as needed
- Informing all affected stakeholders about decisions
Thanks for “Software Requirments Essentials By Karl wiegers|Candase Hokanson” if you have more time better to read the book, My post is the short note of the book. 🤓
