3

The first three chapters in arc42 are related to software requirements:

  1. Introduction and Goals
  2. Constraints
  3. Context

Most projects start with a detailed specification (hopefully) already containing all requirements.

Now my questions (which are - I guess - mainly best practice questions)

Should I copy the requirements which are relevant for the architecture in case that people only read the architecture documentation?

Or are those requirements for the template different to the main project requirements?

rdmueller
  • 10,742
  • 10
  • 69
  • 126
  • Isn't this better asked at [Programmers Stack Exchange](http://programmers.stackexchange.com/), as it's not really tied to programming *per se*? – Jongware Sep 21 '14 at 21:33
  • This question appears to be off-topic because it is about software development methodology – Peter O. Sep 21 '14 at 21:46
  • 1
    But here on SO is the right audience, isn't it? And shouldn't documentation be part of programming? – rdmueller Sep 21 '14 at 21:49

1 Answers1

3

Since I now had enough time to think about my own question, I will now try to answer it myself:

When you face business driven project, the requirements found in the specification will differ from the requirements which drive your architecture. So you will have to analyze the requirements and extract requirements for your architecture - these are most likely new one and it might make sense to take a note which business requirements where the driver for your architecture requirements.

Example: The business requirements state that your app has to produce three different reports. These requirements will describe the reports in detail, but those details do not matter much regarding the architecture. But the fact that you may need a reporting module with the right capabilities might be the right requirement for your architecture. And that's what should be written down in your arc42 documentation.

rdmueller
  • 10,742
  • 10
  • 69
  • 126