Talk:IEEE 1471

• I've added a couple of words that have taken hold in our discussions about defining requirements through the means of Viewpoint Advocacy Groups/Tasks/etc. This fits in nicely with the spirit of IEEE-1471 which seeks to be advisary and not prescriptive. --Morgaine Dinova 01:24, 12 October 2007 (PDT)

References

• Added section with 3 external links to IEEE-1471 resources.
• This stemmed from today's AWGroupies discussion which highlighted the misunderstandings that exist between developers (SLdev was mentioned) when discussing their somewhat different ideas using inconsistent terminology. The end result isn't helpful, causes friction, and ultimately is just a waste of time. IEEE-1471 can be quite helpful even if used only conversationally. --Morgaine Dinova

• As an example, the client/server divide often causes communication difficulties:

Client guy: "I want X in the server."

Server guy: "That's actually a client issue, I'm not interested."

IEEE-1471 acts against this communication breakdown. It tells the Server guy to answer:

Server guy: "The system needs to satisfy multiple stakeholders, please detail the viewpoint that you need satisfied."

However, this is *NOT* a copout or brushoff by the Server guy, because he is then obligated to deliver a view that shows the design to be conformant with the expressed viewpoint, with 1:1 traceability. If he cannot show early conformance within such a view, he cannot claim to be engaged in satisfying the requirements of that stakeholder. Then his brushoff is in the open.

This is designed to keep stakeholders happy while at the same time giving designers (who are also stakeholders) a relatively stable and consistent set of goals, and to deliver an appropriate system, not just some random thing that popped out of the designer's head. :-) --Morgaine Dinova 06:04, 10 October 2007 (PDT)

• It's worth pointing out that this has nothing at all to do with development methodologies. It applies just as much to traditional methodologies as it does in eXtreme Programming, or indeed even when there is just a single developer. The only thing that it assumes is that the developer(s) wish to satisfy the concerns of the parties affected. It helps to assure that and to provide a purpose and a lightweight structure for architectural documentation. --Morgaine Dinova 10:04, 10 October 2007 (PDT)

• Section renamed from Helping system designers speak a common language. --Morgaine Dinova

---

moved IEEE 1471 related discussion from the glossary page over to here (forgot that when refactoring, ooops). Dr Scofield 09:09, 12 October 2007 (PDT)