This issue takes those relationships, and applies them in a requirements management context.
Show a nesting/tree view structure in epics and issue list views.
You are able to manage "requirements" represented by issues/epics in this way.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@Jewell : Can you take a look at the above and see if it makes sense? In particular, I wanted to understand more how customers would use the relationships between requirements in terms of "satisfies", etc. And then also perhaps we can link to testing objects in a separate issue.
@Jewell : At GitLab (and at many organizations that run Agile-like methodologies), scope is not tracked as strict "requirements". Rather, teams analyze the business problems and ship iterative solutions addressing those problems while working with the users of the software. So requirements management as a methodology I understand will be very interesting to industries where there is stricter control on what is to be built and communication and agreements of that upfront before any software is created. I'm fairly certain that GitLab has not worked in this way in the past, but at the same time, I'm sure we incorporate some of these new features into our workflow.
Right now in an issue of GitLab, you can attach a file. So if we consider re-purposing an issue as a requirement, we already get that functionality.
The view I've proposed above could be adjusted to be a more traditional requirements-driven interface.
@Jewell : Can you describe how requirements would be used? I can think of a few scenarios and wanted to verify these:
A client creates a list of requirements and hands them to a team to a develop.
Or in the case of software of an RFP (request for proposal), an organization has a list of requirements, and publishes it to multiple competing companies. Each competing company takes the requirements list and comes up with a plan, listing out specs that fulfill the requirements, and providing a timeline and a budget and sends it back to the originating organization as a bid.
During development, work is done step by step, and requirements are checked off as it is considered "done". This could be after the code is shipped, or tested in production, or some combination of criteria.
Additional use cases of requirements traceability and coverage by test cases. I.e. the goal is to ensure that there is 100% test coverage of all requirements.
If we could get into more details about these with customers that would be great.
In my view, requirements are a set of user-facing behaviors that are organized logically from an overall UX perspective, which differentiates then from epics, which are time-sequenced vertical slides of UX. The UX of a subsystem will grow and change over time as epics are delivered that affect it.
Consider that issues are by definition able to be closed. A requirement may not be.
Separating requirements in its own project section might make sense though. I'd suggest a page listing requirements with individual IDs that can be referenced to in the Issues section of the project (in much the same way we use labels).
Requirements should be considered living documentation and the source of truth for the application. If there is ever an issue with the functionality one should be able to go back to the requirements. Sometimes, an application is coded incorrectly, but sometimes it was coded exactly as expected and as the requirements state. It still might be a business "miss" and the end users need/want something different, but this can be a very important distinction for some companies to make, because then you are either dealing with defect correction or an enhancement and those usually work out of different budgets. Having this source of truth is important!! Also, requirements should be seen as ever-changing and evolving. There needs to be version control so someone can see what today' behavior is, but can also how those requirements are changing as you continue to work on the project. Various industries have different levels of control around this, but it is something that everyone will need to some extent.
@nickleonard@gweaver I'm sharing this with you because this is very similar to the discussion we were having about having issues and tasks appear in the list side by side.
@amandarueda Is this issue refined completely?
From a user's perspective, I see a surprising lack of take-up on the GitLab side.
For example, no planning for this item.
@sander_maijers In order to meet our current Portfolio Management direction, we have unfortunately decreased investment in our Requirements Management, Test Management and Design Management categories. We will continue to address defects and support community contributions but we are not planning to make significant improvements at this time. I'll keep this in the backlog in case the investment decision changes.
@amandarueda While the Issue Description mentions requirements, materially, this is not related to the current Requirements feature but rather a more comprehensive UI view on Epics. This functionality is partly covered by Roadmap and by drilling down individual Epics, which lists ancestors and parents. I think @victorwu is suggesting to take the inherent treelike data model for Epics and such (like work items) further into the UI, by reducing the 'listing' UI paradigm and increasing the 'expanding and folding' UI paradigm.