... newer stories
Sonntag, 4. März 2007
Thema: Analyse
Scott Sehlhorst schreibt einen interessanten Artikel über Business Requirements, dass sie relativ stabil sind. Die Bedingungen eines Geschäfts, also der Markt in dem das Geschäft agiert, ändern sich relativ langsam. Im Vergleich zu den System Requirements sind die Business Requirements also relativ stabil.
Geht man bei der Analyse von den stabilen Business Requirements aus und verbindet die System Requirements streng mit den Business Requirements, desto stabiler wird die Systemspezifikation.
Wichtig ist noch, den Scope eines Projekts in Bezug auf die Business Requirements zu definieren, um Scope Creep zu verhindern.
Sein Fazit ist, dass Business Requirements essenziell und wichtig für ein Projekt sind, insbesondere wenn die System Requirements nicht einfach sind.
Interessant in diesem Zusammenhang finde ich die weiteren Faktoren, welche bei der Definition der System Requirements berücksichtigt werden. Die System Requirements werden aufgestellt auf Basis der Business Requirements, von Randbedingungen / Einschränkungen des Lösungsraums sowie der Kreativität.
Wie oft ändern sich Randbedingungen?
Der kreative Anteil der System Requirements ist sicher nicht sehr stabil. Schließlich basieren diese auf den Erfahrungen aus ähnlichen Systemen, aus verfügbaren Technologien und aus üblichen Ansätzen in ähnlichen Problemstellungen. Diese ändern sich in der IT relativ schnell. Jeder weitere befragte Stakeholder kann theoretisch eine andere Meinung haben und die bisherige Kreativität infrage stellen...
Scott Sehlhorsts Erklärung der Business Requirements greift mir allerdings etwas zu kurz: Sie wären das "was", während die System Requirements das "wie" beschreiben. Ja, das stimmt, aber... (vgl. "Was und Wie")
Meine Erklärung im Artikel über Business Goals gefällt mir noch immer ganz gut...
Dennoch teile ich Scott Sehlhorsts Schlussfolgerung, dass Business Requirements die wichtige Basis für jedes Software-Projekt sind. Ohne sie fehlt die wichtigste Basis für System Requirements und deren Priorisierung.
Geht man bei der Analyse von den stabilen Business Requirements aus und verbindet die System Requirements streng mit den Business Requirements, desto stabiler wird die Systemspezifikation.
Wichtig ist noch, den Scope eines Projekts in Bezug auf die Business Requirements zu definieren, um Scope Creep zu verhindern.
Sein Fazit ist, dass Business Requirements essenziell und wichtig für ein Projekt sind, insbesondere wenn die System Requirements nicht einfach sind.
Interessant in diesem Zusammenhang finde ich die weiteren Faktoren, welche bei der Definition der System Requirements berücksichtigt werden. Die System Requirements werden aufgestellt auf Basis der Business Requirements, von Randbedingungen / Einschränkungen des Lösungsraums sowie der Kreativität.
Wie oft ändern sich Randbedingungen?
Der kreative Anteil der System Requirements ist sicher nicht sehr stabil. Schließlich basieren diese auf den Erfahrungen aus ähnlichen Systemen, aus verfügbaren Technologien und aus üblichen Ansätzen in ähnlichen Problemstellungen. Diese ändern sich in der IT relativ schnell. Jeder weitere befragte Stakeholder kann theoretisch eine andere Meinung haben und die bisherige Kreativität infrage stellen...
Scott Sehlhorsts Erklärung der Business Requirements greift mir allerdings etwas zu kurz: Sie wären das "was", während die System Requirements das "wie" beschreiben. Ja, das stimmt, aber... (vgl. "Was und Wie")
Meine Erklärung im Artikel über Business Goals gefällt mir noch immer ganz gut...
Dennoch teile ich Scott Sehlhorsts Schlussfolgerung, dass Business Requirements die wichtige Basis für jedes Software-Projekt sind. Ohne sie fehlt die wichtigste Basis für System Requirements und deren Priorisierung.
... Permalink ... kommentieren (0 Kommentare)
... older stories