No Jira, No Problem: A Requirements Repository You Can Build in SharePoint
Key Takeaways
- A working requirements repository can be built using Microsoft Lists and SharePoint—tools already available in most Microsoft 365 tenants—without procuring a dedicated requirements tool like Jira or Confluence
- Every row in Microsoft Lists has its own unique URL, which lets business analysts link directly to individual requirements from SharePoint pages, embed them in Teams conversations, or share them with specific stakeholders
- SharePoint sites can be configured for both internal and external stakeholders, making the SharePoint + Microsoft Lists combination a working requirements management alternative when Confluence licensing is restricted to internal users
- Ask SharePoint admins to designate you as "owner" (not member) of the site—this gives business analysts direct control to add and remove stakeholders without depending on IT for every access change
- Known limitations: the Microsoft Lists view threshold is 5,000 rows, and SharePoint cannot export a collection of nested pages as a single printable document
Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.
I recently found myself in a bind. There was no dedicated requirements repository available in the organization I was working with. Requirements were generally contained in a single Excel spreadsheet or in a Word document. Although Jira was available, the Atlassian administrators had restricted the ability to add new fields to a Jira issue (such as MoSCoW prioritization or the status of the requirement). Additionally, Confluence licences were only available for internal users, and my project had external stakeholders.
These combined factors created a business analysis governance issue, as the organizational restraints made it difficult to manage the requirements. There was no budget for a dedicated requirements tool, and I couldn’t delay the project by more than a couple of weeks. My first thought was to revert to using Word documents and Excel spreadsheets stored in a folder. However, I had no desire to manage feedback from stakeholders using a combination of email, track changes, and comments.
Thankfully, the organization was a Microsoft shop. This meant the applications SharePoint and Microsoft Lists were freely available. I had used a combination of MS Lists and SharePoint before, and I knew that I could combine both of these applications to create my own requirements repository.
If you have access to SharePoint and MS Lists in your organization, you can use the method I describe in this article. Although I don’t cover all aspects of creating the repository, there should be enough information to enable you to explore the concept in more detail.
Microsoft Lists Are Your Friend
The first step is to use MS Lists as your underlying requirements database. It’s basic, but it has some features that are more useful than Excel.
You can set up your MS List however you want. You can have one large MS List that contains all of your requirements (although there’s a List View threshold of 5,000 rows), or you could have multiple MS Lists with each one dedicated to a particular epic or set. You can create columns in your MS List (just like in an Excel spreadsheet), and there are numerous data types available, but the Choice data type is the most practical.
The Choice data type lets you set up various elements such as the requirement state, the MoSCoW status, or anything else you want to define. This data type allows you to select one or multiple values. The sorting capabilities in MS Lists mean requirements that meet one or more specified filters (which includes the Choice) can be easily found.
Using MS Lists allows you to record any type of requirement along with all associated information, such as the stakeholder names, priority, review status, review dates, and the sign-off date. MS Lists has default columns that record when the requirement was created, when it was updated, and who updated it. It also has automatic version control. Since you can add any additional column as needed, you can also enhance your requirements traceability by setting up parent/child relationships using links.
The key advantage to using MS Lists for requirement management is that every single line in the MS List has its own unique link. You can link directly to the line without having to link to the entire document. This means stakeholders can comment on individual requirements in the MS List. MS Lists can be viewed online, in real time, by any of your stakeholders. They can collaborate via Teams with the business analysis professional or each other, as needed.
Finally, the MS List can be exported as a CSV or Excel file for archival purposes at any point in time.
Use SharePoint Pages to Create the Layout
A SharePoint site can be for internal users only but can also be for both external and internal users. This is a standard feature in SharePoint. Your SharePoint administrators should have the ability to set up either type of site for you, depending on your organization’s policies.
Note that you need to have the SharePoint admins add you as an owner to the site, not as a member. This will give you control over the site and let you add or remove members (users) as needed without having to ask the SharePoint administrators. Only invited users can access the site. This allows you to dynamically manage stakeholder access.
Some basics about SharePoint: it uses a concept called “pages,” which function similarly to Confluence. The application also comes with a number of standard web parts that can be dragged and dropped onto the page’s layout. It provides several navigation options (including a sidebar) that allow you to nest pages hierarchically.
Additionally, versioning is a standard SharePoint feature, allowing you to revert to a previous version if something has gone wrong. You can also revert to a previous version of an MS List.
Combine SharePoint Pages and MS Lists to Create a Requirements Repository
The secret sauce is combining SharePoint and MS Lists to create and manage the repository.
In my SharePoint site, I created nested pages that allowed me to group features together under a main topic (or epic, if you’re using agile). The main topic summarized the related features, while the feature pages contained an overview and information about the specific feature to provide context.
Each feature page contained a list of requirements as clickable links. These are the links to the individual lines contained in the MS List. When a stakeholder clicks on the link, the columns for that line are displayed as a form on the SharePoint site. Displaying the information as a form is automatic—you don’t need to set anything up for SharePoint to do this.
The stakeholders could either edit it directly, add comments, or print the form. All stakeholder comments are visible on the requirement, removing the confusion as to which line in a Word document was actually supposed to contain the feedback. For stakeholders who don’t want to leave feedback on individual requirements, they can leave feedback on the SharePoint page.
By using MS Lists, you have one place to manage your individual requirements. The SharePoint pages let you knit the information together. This includes the ability to embed other media types. For example, you can place a Visio file onto the page. The Visio diagram is visible to the stakeholder, allowing them to zoom into the diagram and move around it without needing Visio access.
Users who prefer printed materials can export a SharePoint page to Word or PDF (much like Confluence). The only caveat is that unlike Confluence, a user can’t print a collection of nested pages as a single document.
If you’re working entirely within the Microsoft ecosystem, developers can use Azure DevOps with Power Automate connected to your MS Lists, allowing you to maintain a single source of truth for multiple audiences. Power Automate can bi-directionally sync your requirements repository (the MS List) with the delivery team's development backlog in Azure DevOps.
Building a Requirements Repository with SharePoint and MS Lists: Key Takeaways
If you’re in a Microsoft-based organization and want to create a requirements repository that’s unlikely to run into licensing issues, has adequate permissions, and lets you mix and match how the information is presented, you could experiment with using a combination of MS Lists and SharePoint pages and see if this works for you.
As SharePoint and MS Lists are Microsoft products, a wealth of details is accessible online. Various books are available if you really want to dig into the applications in more detail.
SharePoint and MS Lists aren’t perfect, and they have some limitations. If you’re new to using these applications, I would advise taking some time to read the available information and create an experimental SharePoint site to understand how it works. However, once the basics are mastered, you’ll be able to build your own requirement repository without having to rely on others to administer it for you, apart from the initial creation of the site.
Explore What's New
Looking for more practical business analysis tools and templates? Check out IIBA's KnowledgeHub—the community-built library of templates, techniques, and applied resources for the situations you face in your day-to-day work.
Explore it today
About the Author
Yvonne Harrison, CBAP, is a senior Business Analyst working as an independent consultant. With over three decades of experience across public and private sectors—including defense, taxation, and education—she specializes in requirements lifecycle management and pragmatically aligning technology to business strategy. Yvonne is dedicated to sharing practical, real-world frameworks with the global business analysis community.
