I have typically worked on projects with less in the way of formality and without a system architect role on every project. So the use case typically accompanied a broader system design document with the approach outlined for the project. Together these two documents provided the input the developers needed too begin to write code. I think I’ve also been working with fairly senior level developers and they are able to break down the functional requirements into system requirements and begin to write code. Typically I also deliver wireframes with use cases. So the requirements are fairly detailed, in terms of fields, logic, and business rules before they end up in the hands of the developers.

I’d be interested to hear more from other readers as well about the contents of the technical specs you hand off to the development team and how much of the detail you deliver vs. a solutions/systems architect you might be working with?

Laura

Basically usecase case will only tell “what to implement”, the functionality. These usecases can be embedded into the FRS. The end audience of a use case is the solution architect or system architect, QA team and not developers. You cannot expect dot net or java developer to understand functional terms.

Functional req after analysis is converted into prototypes, screen level description, a level which completely described “how to implement” the functionality. The end audiences here are the developers.

System documentation will include the details of finished system you won’t be adding the crude prototypes but will be adding the final screen shots of the finished systems. This document will tell user ‘what is implemented”. The end audiences here, as u have correctly mentioned are business analysts, project managers, and product owners.

That’s a lot of re-use from a single artifact.

Leslie.