Software Artifacts Vs. Requirements

The relationship between artifacts and requirements is not straightforward. This is not only because a requirement itself is a type of artifact, but mainly because artifacts can represent both requirements and designs. While some artifacts represent what users really want from the system and are part of the contract with stakeholders, others can be just internal designs "hidden" from the stakeholders.

Depending on the specific project, selected development approach, and other conditions, the following scenarios can occur:

1. The development team can design the system from high-level requirements
   • Thanks to agility, effective communication, and strong collaboration within the team, the solution will be developed directly from high-level requirements without any design artifacts.
2. The analyst outlines software artifacts directly from the high-level requirements elicited with stakeholders
   • No high-level requirements specification is created, and the software artifacts are the only documentation.
3. The analyst identifies high-level requirements, then creates concrete designs and represents them using software artifacts (screens, interfaces, processes, etc.)
   • "The user must be able to create a new invoice. The following invoice data are required:..." - this requirement is transformed into a screen design that shows all required fields, buttons, and layouts. The high-level requirement is then replaced by this artifact.

Once the textual requirements are transformed into artifacts, they are no longer needed as separate items and must be discarded. They should be kept only to provide context for the software artifact, perhaps in the form of a note. The primary goal is to develop the solution, not to synchronize requirements back and forth (working software is the primary goal).

Summary:

1. High-level textual functional requirements are not necessary, and nobody will miss them if concrete designs are available. Textual requirements are only needed when the analyst starts from scratch and has no idea about the solution.
2. Once textual requirements are transformed into artifacts (screens, use cases, business rules, etc.), they are no longer needed.
   • This is not always possible, especially in environments where textual requirements specifications must be used as a communication tool.
3. If design artifacts are available, related requirements should be reflected directly in the artifacts.
   • The requirement "The list of invoices must be sorted by the total invoice amount" specifies a concrete list on a concrete screen, so it should be placed there.
4. If the required change is directly related to a specific artifact, there is no need to describe it in text. So, if the analyst knows that what the stakeholder really needs is changing a button color from red to green, a valid form of the requirement is to state: "Change the color of the red button on SCR-123 to green."