As mentioned here, one of our EA-projects is "Common methods and templates for requirement specification". The project was initiated by our GAP-analysis and the main background is to mature our organization in requirements. The initiative is perfect for incorporating our EA-principles, reference architecture, standards etc. in practical projects. I am also working with implementation of a common process for system development and -acquisition based on Unified Process (UP), which is much centered at Use cases and Architecture. Though this kind of architecture is focusing on a lower level than EA, we have made good guidelines and processes for connecting our EA to architecture requirements and non-functional requirements in requirement specifications.

In context of requirement specification I participated in a network group meeting arranged by Dansk IT. It was a very giving meeting based on a case and with a lot of good discussion. Dr. Soren Lauesen also participated in the meeting and initiated a lot of good discussions.

Some of the new points for me, are:

- The purpose of the specified business unit (and system) is very important. The purpose can be defined as "A short and clear description of how the project will change our business situation" or where the project will move the specified business unit. In this context all the functional requirements must be mapped against the purpose. You should ask, if and how each functional requirement (encapsulated in Use cases) is supporting the purpose or not. If not, maybe is the requirement not relevant. So is this process very important in scoping projects and managing the Cost/benefit for the clusters of functional requirements.
- Background for the system is also very important and can be defined as a "Short and clear description of why it is important to start the new project and which consequences an unchanged as-situation will have". With focus on this and with good governance many projects will still be ideas and only real business improvement projects will bee implemented.
- The main elements of a requirement specification are the business functionality aka functional requirements for a system. This is according to UP-best practices and in most successful practical cases done by Use cases and Business Concepts (-domains – Danish: Forretningsbegreber). This is done by iterative working with Use cases and Business Concepts, by keeping Use cases against the Business Concepts and asking, which Business Concepts do the Use cases influence and more detailed which Business Concepts to the Use cases create, read, update and delete? This can be done with a CRUD-matrix by keeping all the Use cases against the Business Concepts. This will result in a complete Business Concept model, which can be mapped to a datamodel or ER-diagram in the design-phase. In this way you can be sure to have specified all the requirements.
- The typical Use cases in requirement specifications are system-focused. For getting more innovation and be more business focused, there is need for something before the systemoriented Use cases. This can be done by either Business Use cases or Business Process Modeling (BPM). I think this aspect is very interesting and I will further work with this and clarify the transition from generic holistic across organizational Business Processes to more Systemoriented Usecases.
- Sketches of GUI are very good in communication Use cases with end users and can be used in the requirement process, but the sketches may not be distributed to the vendors, because it will reduce their innovation. We have experienced, that some vendors are seeing sketches as design and they implement the sketches in design by 1:1:- )