Add a comment


Re: Software Architecture Document Guidelines

I think it makes sense to keep the non-functional view and justification separate.

In my mind, the non-functional view captures the non-functional requirements - it sets out what your architecture is trying to achieve. This is sometimes a document in its own right, sometimes owned by someone other than the architect. Nonetheless, the audience is often non-technical, being required to agree that your interpretation of the NRFs is correct and complete.

The justification of the NFRs is for traceability, to show that the proposed architecture is up to the job. Again, this could be separate, the results of prototyping or industry benchmarks.

For certain sets of requirements there's no doubt benefits to merging the two, perhaps where a simple "requirement/design decision" matrix will suffice.

Is it worth us adding something to the guidelines to capture this flexibility or even creating an "SAD-lite" version?

Re: Software Architecture Document Guidelines

HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
E-mail address
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).