Affiliated with:

Fundamentals of Requirements Management

fundamentals-of-requirements-management

Requirements management is the process for collecting, analyzing and implementing the business-stated expectations and functionality. Managing requirements is a fundamental practice for supporting positive organizational change.

Requirements management is a fundamental component of how organizations manage change. Yet, while program and project management receive significant attention, funding for training and tools, requirements management often lags. As a result, projects often manage requirements in a siloed mode which results in conflicts, inconsistent functionality, and resources spent on rediscovering information that could have been shared. What should a smart organization do to create a sustainable requirements management process?

Recognize that requirements management is wider than any individual project.

Requirement artifacts represent knowledge about the organization. Context and conceptual data models, process flows, decision trees and user journey maps can tell how the organization is managing its business. Captured user stories, business rules and scenarios create structured information that can be used to develop training, procedures, audit requirements, testbeds, and business continuity planning. Requirements captured by previous projects may (and should) be revisited by new initiatives for reuse, relevance, and to avoid conflicts.

How this should be done? As with project management, it requires adopting a methodology and adapting it to the needs and specifics of an organization. This allows the organization to create sustainable processes and continuity which is essential for knowledge sharing and requirements reuse.

Requirements management methodology

A requirements management methodology does not have to be complex and intricate. Simpler is almost always better unless the organization is a conglomerate spanning multiple jurisdictions and industries. Establishing a methodology requires:

  • Standard methods and process
  • Standardized deliverables
  • An agreement to follow the above

Applied to requirements, it would include:

  • A standardized approach to requirements analysis used across the organization and its different projects.
  • Central shared repository of requirements where new projects will have access to requirements of previous projects (and with sufficient maturity, requirements are mapped to the existing solutions where they are implemented).
  • Templates and job aids for frequently used requirements artifacts.
  • An overall climate that fosters sharing, learning and the business analyst mindset.

Use the methodology on enterprise projects and initiatives

Once the methodology and standard process are established, they need to be used consistently.

There are several key steps that organizations can use to establish and strengthen their requirements management methodology.

Planning requirements analysis

Whether an organization is using waterfall or variations of agile methodologies, product and project planning is an essential step. Business analysis activities also require planning. The requirements management plan, its key milestones and activities should be incorporated in the overall project management plan.

Business architecture artifacts, if available, will provide a foundation for a requirements analysis plan:

  • Strategic objectives of the change (to guide project success criteria and user journey priorities)
  • Change boundary and context (to clarify the scope)
  • Business capabilities addressed by the initiatives (to indicate impacted process groups)
  • Affected business functions (to identify requirements stakeholders)
  • High-level customer journeys (to start planning epics and themes)
  • Audit, compliance, and governance considerations (to reference existing policies and business rules)

This architecture foundation, as well as the methodology and maturity of the organization, will help define appropriate requirements analysis activities:

  • artifact collection
  • immersion
  • user story mapping
  • requirements workshops
  • process mapping
  • capturing and reviewing requirements or user stories
  • user story reviews
  • validation activities

These planning considerations, in turn, allow to make more intelligent estimates of the time needed for requirements analysis, and frequencies and durations of the activities that require stakeholder engagement.

Assessing requirements risks

The latter component – time-bound plan – may be something a business analyst finds difficult to articulate and commit to. The main uncertainty will come from the nature of the project and associated risks:

  • The scale of change (minor, major, transformational)
  • Business knowledge (expertise available or hard to find)
  • Technology (proven and established vs. emerging or unknown)
  • Acceptable uncertainty (agile approach with a high tolerance for uncertainty vs. rigid scope, timeline, or budget constraints)

Requirements planning exercise will highlight these risks and the need for contingency planning. More complex changes involving multiple departments, partners, and many existing systems, will have higher scope uncertainty until requirements have been crystallized and captured at some level of detail.

In less mature organizations, project managers may not welcome the need for accommodating requirements risks and planning for potential scope creep and scope change. More experienced project managers will know that it is much better to be prepared for reassessment and negotiations when significant gaps or issues are discovered during the requirements phase. Supporting business analysis resources in delivering quality requirements will be the best mitigation strategy.

Managing the business analysis process

Business analysis activities can be grouped into stages of the analysis process as shown below:

A Profession And A Mindset
Source: “Business analysis: a profession and a mindset” (Yulia Kosarenko, 2019)

The process does not have to be linear. These stages may be present on a micro-scale in each cycle of iterative product development. Prioritizing may be done first to identify a set of features that require analysis for upcoming iterations. The bulk of discovery will be done upfront but may be refined and expanded as the project continues or the business context changes. Validation should be continuous.

However, each of the stages is necessary for quality requirements analysis, and specific activities to support each stage must be chosen based on the nature of the change and the needs of the stakeholders.

Requirements repository and tracking

Spreadsheets, however ubiquitous they are in your organization, should not be your tool of choice for requirements management. This capability is a foundation of the organization’s data management and change management programs and should be integrated with the solution delivery tools used in the company. While there are many requirements management tools on the market, each company must make this decision based on what tool has a higher chance to succeed and fit in with the rest of the tools used to develop, test, implement and support business applications.

While the tool provides a repository to store and manage the requirements, the methodology is key to using the tool effectively:

  • Establish requirements metadata (attributes)
  • Track requirements through the lifecycle (future, in development, implemented, deprecated)
  • Track business ownership or requirements and strategic objectives they should support
  • Trace requirements to business applications supporting the required functionality
  • Trace requirements to design features, system specifications, test cases

Managing business analysis resources

Enterprise requirements management is inseparable from the topic of managing business analysis resources. Getting value from a shared requirements repository will be based on the organization’s ability to promote and build a Business Analysis Center of Excellence. This requires:

  • Recognizing business analysis as a function
  • Creating a business analysis team with appropriate education
  • Nurturing leadership of the business analysis team (ideally an individual with business analysis or business architecture background)
  • Supporting professional development and upskilling
  • Actively building and using best business analysis practices
  • Nurturing buddy and peer-to-peer mentorship within business analysis team
  • Identifying and growing internal candidates to join the BA team from other parts of the organization

Conclusion

Establishing a mature requirements management practice requires effort and focus. It is an investment that will pay back manifold with improved quality of the requirements and final products – solutions to business problems.

LinkedIn
Facebook
Twitter

Yulia Kosarenko

Yulia Kosarenko is a principal at Why Change Consulting Inc. working with various industries to grow mature enterprise architecture and business analysis practices, plan and execute digital transformation programs, and use analytics to make better business decisions. 

Yulia’s career spans more than 25 years of bringing IT and business together in insurance, education, logistics, banking, payments, and pension investment industries. She is the author of the books "Business Analyst: a Profession and a Mindset" and "Business Analysis Mindset Digital Toolkit" and teaches business analytics to post-graduate students in Toronto.

Yulia is active in business analysis and analytics communities, leading webinars, speaking at conferences, developing online courses, and conducting training.

© Since 1997 to the present – Enterprise Warehousing Solutions, Inc. (EWSolutions). All Rights Reserved

Subscribe To DMU

Be the first to hear about articles, tips, and opportunities for improving your data management career.