Requirements projects

Whether written up in Documents, or authored with integrated tools, Requirements in Polarion are a type of Work Item, that is, an artifact that is tracked and managed through a process. You can customize your project configuration to support whatever semantics you use. For example, if your organization uses the Scrum methodology, you might name the Work Item type that represents requirements as User Story. Regardless of semantics, requirements are tracked and managed the same as any other artifact — development tasks and change requests, or QA test cases and defect reports. Artifacts created by other teams can be linked to requirements to create traceability. For example, QA engineers can link Work Items representing test cases to Work Items of the Requirement type that the test cases verify. Engineering can link Work Items representing tasks and change requests to the requirement they implement. Work Items representing defects found by QA can be linked to an implementation Work Item that fixes them, and easily traced back to that item's requirement or requirements.

When preparing to use Polarion for requirements, you need to think about how the requirement Work Items you create will be linked to others like tasks and test cases. For example, you will need to decide what processes will be managed in a given project. Will requirements have a separate project, or will they be part of the same project used to manage implementation and testing? Maybe Requirements and QA will have one project, and Engineering a separate project. All approaches are possible. Linking for traceability across projects is a little more involved than when all artifacts are managed in the same project, but it is still quite feasible. In any case, your requirements team will need to coordinate with these other teams to decide the best approach to projects.