As always Business Analysis is open to interpretation. I'd appreciate people's views on creating Functional Requirement Statements from models.

In the "new" world, requirements statements are often considered lengthy, unnecessary, redundant. Modelling (i.e. Use Cases) can be seen as a way of replacing requirements statements. Yet I've seen a number of posters (including dwwright) mention creating requirements statements after modelling. I'd be interested to know how that's done, and why. I would have thought it difficult to maintain both models and a long list of requirement statements.

Appreciate your thoughts.

Hi Panofoot:

In my previous post on this thread I explained why [functional] requirements modeling is done prior to writing of requirements, but I forgot to discuss how its done.

Once you have rigorously identified a process's or function's inputs and outputs, you have successfully scoped out that  process/function.   Now you just  zero into the process/function and flow chart out how those inputs are used to create the outputs.  Obviously, creating  written functional  requirements off of a rigorous flow charts  is fairly straight forward.  If the flow chart does not tell you how to word a requirement, at least it will point you in the right direction. And the flow chart ensures that you have properly considered the extent of the requirements for the process/function.

Tony

Hi Tony,

Thanks for your replies.

I think it's very fair to say that everyone has different viewpoints dependent on what they've been exposed to. It seems to me that you see 'To-Be' analysis as identifying processes and inputs/outputs. From everything I've learnt, this approach is more akin to a structured development approach. I still very much use process diagrams/activity diagrams to model 'As-Is' Business Processes, and to a certain extent use them for depicting complex system processes, but don't depend on them to model the end-to-end system.

When it comes to Use Cases, it has been argued that they are simply a tool for exploring requirements in the first instance. Stakeholders may not be in a position to define all of the processes and inputs/outputs for a new system. However, by looking at the goals and tasks that a user may want to achieve, you can arrive at the functional requirements more quickly.

I believe that the argument for then writing out functional requirements statements (e.g. from Use Cases) is that with Use Cases, functional requirements can span many Use Case descriptions. When it comes to design and development, it can be difficult to see the wood for the trees as it were when knowing what the system should do on a functional level. That being said, the downside (unless you throw away your use cases/models) is that you have to maintain more documentation.

As an aside, you were discussing in a recent thread the subject of "partitioning" requirements. What do you mean by partitioning? Are you referring to decomposition? (i.e. functional decomposition, feature-list decomposition).

PS: Kmajoos: You mentioned that Martin Fowler wrote "Requirements are NOT usecases; and usecase are NOT requirements". Use cases aren't requirements in their own right (especially if you're referring to the 'goal' that a use case represents), but a use case description does contain functional requirements.

Panofoot