Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Models to Functional Requirements
Previous Previous
 
Next Next
New Post 10/13/2009 6:13 AM
User is offline panofoot
11 posts
10th Level Poster


Models to Functional Requirements 

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.

 
New Post 10/15/2009 7:45 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Models to Functional Requirements 

Hi:

One of the main reasons BAs model first is that a system, especially other than a small system, can have many processes/functions  happening/executing at the same time.  In other words, a system is kind of multidimensional.    However text is kind of single dimensional.  That is that it is sequential: one thing happening after another.    Therefore, the problems with proceeding first with text based requirements are that:

*  It is next to impossible for the analyst to envision what the system will do without first modeling

*  It is just as hard to try and describe a multidemensional entity is to do with just a single dimensional tool.

Now regarding "the new world", i.e. the Agile world, the key is to model "just enough".   That is to model what is essential.   Now the question is "What is essential?"   Looking at functional modeling (which rightfully drives data and state modeling) the most essential are identification of the process/function and, just as important, identification of the inputs to and outputs from/to the process/function.  A huge problem with use cases is that inputs and outputs are ignored in the graphical models.  Use case can address inputs and outputs  in their supplemental text, but such an approach is very lacking in rigor.  Inputs and outputs have to be captured in the graphical model.

Tony

 
New Post 10/15/2009 9:51 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Models to Functional Requirements 

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

 
New Post 10/17/2009 12:53 AM
User is offline KJ
243 posts
6th Level Poster


Re: Models to Functional Requirements 

Requirement governs behaviour and a Use case defines a  behaviour. I concur with that philosopher dww -right!

In the original UML distilled the author echos the following sentiments "Requirements are NOT usecases; and usecase are NOT requirements". Then he got cocky and asked the reader to repeat the sentence like an envangelist on the Christian Channel. 

warm regards,

K

 
New Post 10/17/2009 11:47 PM
User is offline panofoot
11 posts
10th Level Poster


Re: Models to Functional Requirements 

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

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Models to Functional Requirements




Latest Articles

Six Estimation Safety Tips
Oct 13, 2019
0 Comments
Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry w...
Copyright 2006-2019 by Modern Analyst Media LLC