Product lifecycle management is all about the dynamics between requirements and their fulfilment (e.g., the ability to test and prove that a requirement is fully covered, as defined during the product planning phase). Understanding this relationship, and respecting it unconditionally, allows great products to achieve world-class quality and stability.
For the majority of products, the combination of people, processes, and technology is triggering different forms of changes to the original plan:
- Change that is driven by a healthy progress of the plan. The status of the requirement itself is only changing as the product evolves and progresses to the next stage in its lifecycle (Planning -> Dev. -> Test etc.). This a good problem to have, but all stakeholders involved should be aware to the change in status.
- A forced change is impacting the requirement. Examples of changes include: some of the original product requirement has changed as initial assumptions taken may not fit as initially thought, technical feasibility assumed earlier in the cycle is not valid, a change is forced to the product scope, estimated effort, or the staffing of the project.
- In cases of cross-team collaboration, where the project is being handled by more than one team, or even involves external stakeholders, plans will change more frequently and everyone needs to know of any potential change, and its subsequent impact on the plan.
- Identified quality issues are forcing a change. The testing of a certain functionality has failed, or has been delayed, which requires actions in the plan.
The nature of any product requirement is to evolve and/or change (there is a known say that “every plan is a basis for changes). As most of the product teams acknowledge that, the main challenge they are having is aligning everybody around the same view of the requirements and keep track of any change.
Now that we all agree about the importance of building a single source of truth for everything requirements, the question is how do we blend all of the data that is being used today into a single tool that oversees the entire product lifecycle?
So many types of files are being used today to manage requirements by different teams. The need for a lifecycle management tool is to be able to import all of them, unify their structure and content into a single pain of glass, and to be able to keep track of any changes.
Formats that Organizations Commonly Use
MS Word Doc
Word files are used by many teams for writing up their product requirement documents.
The main concerns around this type of file are how can we make sure that:
1. Everyone has shared visibility to the same version of the file (as there can be endless number of duplications).
2. Only authorized stakeholders can make change a requirement.
3. Any change in the requirement is audited and has digital signatures (optional).
4. All stakeholders are aware to any change (sort of keeping the file in “Track Changes” mode forever?).
When importing requirements from a Microsoft Word document into Helix ALM, you can either create a new requirement document or import requirements into an existing document in the Helix ALM project.
The import functionality also supports rich formatting (images, bulleting, styles etc.) and can automatically identify and treat new requirements in Helix ALM (During the import, Helix ALM will add a new requirement for each paragraph in the Word document that uses a style).
The word document upload does not support the ability to map field-by-field, and it is aimed for import of requirements only, not test cases or issues.
Before
After
CSV and other Table Types
Different text files are widely used to manage or list issues, requirements, test cases, users, and customers. The most common formats are usually csv. and MS Excel (.xls), which by nature behaves as plain text.
When importing these files into Helix ALM, cells/columns can be easily mapped (field-by-field) as new requirements. This type of import in Helix ALM is ideal for large data sets.
It’s important to keep in mind that there is no formatting functionality supported, so any post-upload treat of items cannot be based on pre-defined rules.
Before
After
For example, you may want to do this if you need to manipulate the data outside of Helix ALM or share it with people who do not have access to Helix ALM.
.XML Files
Given its structured schema, an .xml file offers better flexibility when it is exchanged.
Therefore, importing an .xml file into Helix ALM, you not only import requirements but also issues, requirement documents, test cases, folders, users, customers, and test configurations from an XML file exported from another Helix ALM project.
Helix ALM customers find tremendous value using this comprehensive import functionality that include historical elements of such files and also support upload of attachments and preserve links to other artifacts or sources.
It is important to pay attention to the Helix ALM specific XML structure and make sure that any required conversion from other systems is aligned with the product schema.
Before
After
ReqIF
While ReqIF file is also an XML file format (its main value is due to the fact it serves as a standard schema for the exchange of requirements between product and software tools / vendors. RegIF basically defines a workflow for transmitting the status of requirements between all relevant parties.
Helix ALM customers importing the requirements using the ReqIF format can:
- Ensure Traceability - No matter who’s handling of the requirement (internal/external entity).
- Maintain Compliance - Full compatibility between different lifecycle management tools
- Reduce Risk - Replace other non-traceable alternatives for sharing requirements (Word, .csv/Excel, PDF exchange).
- Enhance Collaboration - Full visibility to the requirements and ability to see the impact of any given change.
- Ease of Use - Sharing data related to the requirement using the same structure (IDs, hierarchy, relationship, links etc.).
The ReqIF import functionality offered by Helix ALM allows customers to have each ReqIF file mapped (field-by-field) as new requirements in the system.
REST API
REST API is a modern way to exchange data, which is preferred by many organizations these days. It is very useful for ongoing integrations with other systems.
Do note that the use of the REST API requires custom development to build and maintain integrations.
Back to topManage Your Product Requirements with Helix ALM
Ensuring version control and visibility across all of the member of your team is critical when managing product requirements. With Helix ALM, you can do that.
Score a 20-minute Helix ALM demo today
Additional Resources
- Blog - How Issue Management Helps Shorten Project Times: 3 Examples
- Blog - The Evolution of Planning and Tracking Tools
- Resource Collection - Types of Software Testing