Background: System: Customizing Task Status
Organizations may wish to reflect unique task statuses not currently captured within SD Elements. For example, sometimes organizations want to have a specific state for “Risk Accepted” or “Deferred”.
Adding custom Task Statuses is a major change. Most of SD Elements is designed to allow only three states: Complete, incomplete and not-applicable. For this reason, when you create custom task statuses you will need to map it to a built-in status under the “meaning” column. We recommend only using built-in task statuses whenever possible, as the user experience and integrations were designed specifically around them.
You may encounter situations where a custom task status is important for enterprise adoption. For example, if there is already a process for adopting software security requirements, you may need to reflect the existing process statuses. Another reason for adding a custom task status is when organizations want to reflect a difference between a task that is incomplete versus a task that will never be worked on. In this case, you may want to create a custom task status for “Risk Accepted”. You can determine this by interviewing key stakeholders when you plan for an SD Elements deployment. In particular, ask if the current status convey sufficient information for reporting purposes.
It is imperative to make this kind of change early on, ideally before you model any projects in SD Elements. While there is no defined hard limit for number of custom task statuses, adding more than two will likely significantly degrade the user experience. Also, task status names should be short as certain views may cut off overly long task status names.
- Is there a pre-existing security requirements with different statuses that are not accurately reflected in SD Elements?
- Do the three built-in statutes provide sufficient data for key stakeholders?