Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Will the real Functional Specification please stand up?
Previous Previous
 
Next Next
New Post 8/29/2009 4:37 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Will the real Functional Specification please stand up? 
Modified By Craig Brown  on 8/29/2009 6:37:43 AM)

Does anyone ever think about the cost and value of some of these docs>

I just got one from an analyst that I estimate cost about $45K to produce.  It's valuable and worthwhile information, but I don't think it was worth that much.  Maybe it was a $5-10k document.

Does anyone apart from me ever think about the financial side to this stuff?

 
New Post 8/29/2009 10:49 PM
User is offline Adrian M.
733 posts
3rd Level Poster




Re: Will the real Functional Specification please stand up? 

 craigwbrown wrote

Does anyone ever think about the cost and value of some of these docs

Hi Craig,

You bring up a very good question!  I think that many of us tend to forget to think about the cost of these docs and put them in perspective.

I remember a while back one of my managers, after reviewing one of my docs, asked me: "How many hours did you work on this?"  I don't remember but I must have said something like: 20 hours and then he asked "So would you pay $600 for this document?".  I was stunned because I realized that I would surely not pay $600 for the document I just created.  It wasn't that the document wasn't needed but it was of poor quality and incomplete.

This is not to say that creating documents is without value but it really gave me a kick in the rear-end and forced me to work on good habits and work ethic to develop high-quality documents, complete and with not defects.

So yes - we need to think of not only the cost (how much money did we spend to create the document) but also of the value (what is the financial impact of not having the document).

These days, there is a tendency to shun documents especially large ones - and for good reasons.  Many projects don't need a tone of documentation when the team is small, uses agile practices, may be a one time project with no need for future expansion.  Some teams need documents but they don't have the right talent or they simply use "the template" dictated by some process which was put in place years a go and nobody remembers why and whether the assumptions true back then still hold today.

In my experience, the decision of how much documentation (and if any) to create is not a one time decision.  The analyst and the management team must constantly re-evalute the state of the project and organization, needs of the business, future plans/goals and determine if more or less documentation may be needed.

For example, you're leading an agile team for a health care software vendor.  You use agile practices, you write the user stories on 3x5 cards, once  the iteration is over and the stories have been implemented you dump the cards.  Things work very well!  Product gets updated often and with great impact from the clients.  Everybody's happy!    Then the things talked about in this story (Just What The IT Industry Needs -- More Regulation) become true.  Aka  - the government begins to regulate how health-care software vendors deliver software and they mandate "proof" that you've followed a rigorous process and that you know what your software does.  In this case, you might consider creating and keeping more documentation.

I've worked on projects in an entrepreneurial environment where the key goal of the product was to "get it out there and show it to the investors".  Aka - speed to market was critical so any "non-essentials" were cut including documentation.  We were agile and did "just enough" to get the product out the door.  The project sponsor got exactly what they asked for.

On a different project I worked on we had to develop a new system was for a large Fortune 500 company, in a heavily regulated industry, for a very complex business domain, there was a need to be able to respond quickly to changes in business climate and new laws, and with the goal for the product to be a multi-generation system with a shelf-life of 10+ years.  Do you think we created more documentation then simple 3x5 cards?  You bet!

I just wanted to illustrate that knowing the cost of documentation is very important but as important is knowing the cost of not having the documentation.

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 8/31/2009 8:19 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Will the real Functional Specification please stand up? 

A document is just a container, it's the content that matters. So, any content that is not used by an audience is not worth the effort/expense to create it.

Overall, though, any requirements artifact is an intermediate deliverable, worthless in of itself, worth something only if it drives delivery of a solution. It's effort/cost should be included in the complete business case for delivering a solution.


David Wright
 
New Post 9/1/2009 2:15 AM
User is offline panofoot
11 posts
10th Level Poster


Re: Will the real Functional Specification please stand up? 

Thanks for all the replies.

I thought I might get a few replies along the lines of "It's whatever your company defines them as"!

And that's a fair response, as clearly there are differences in the way some of these documents are defined/perceived.

I guess what I've really driving at is the cut off between Analysis and Design... For a while now I've been relatively comfortable with the idea that a reasonable Requirements Spec/SRS/Functional Spec (call it what you will), will cover WHAT the system is intended to do. So this includes:

 

- Functional Requirements

- Non-Functional Requirements

- Business Rules

- External Interfaces

- Standards, Licensing, Hardware requirements

- Design constraints

All of the above are (where possible) are independent of the actual technology or implementation (Design).

Historically, where a Requirements Document was written as a shopping list of "The system shall"s, the customer might ALSO want to see more detail of the actual "solution" at a high level. That is, "A document showing how the functional requirements are realised as a solution". For this, my organisation (and apparently many others) would create a "Functional Specification Document" or "Functional Design Spec", which is still independent of technology or platform, but provides a function by function, screen by screen "high-level design" of the intended solution.

So, I guess my real question is:

A) In the era of Use-Cases which can describe the behaviour of a system independent of technology/platform, is a "high-level design document" needed?? Granted, it would provide more detail in terms of actual implementation and user-interface design, but isn't this the Design anyway and no longer the analysis? My thoughts are that a detailed enough Requirements Spec with Use Cases is plenty sufficient for both the customers and developers to agree on what is to be developed.

B) Should this "high-level design document" be considered a product of Analysis? In many cases I've come across, it appears that an Analyst would be responsible for creating this. In some cases, the customer creates this themselves (always a worrying situation).

 

Appreciate your thoughts!

 
New Post 9/1/2009 11:15 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Will the real Functional Specification please stand up? 

"The customer may also want to see more detail of the actual solution at a high-level".  Why? Because they don't believe the list of requirements is correct or complete?

Next, are you then saying that having use case replaces functional requirement statements, so a high-level design isn't needed? Because the customer will see the use cases and then believe all of their requirements have been captured?

If the answers to all these are "yes", then I agree that a high-level design is not needed. If any answer is "no", then we can discuss some more!

I follow an approach that creates use cases in order to derive functional requirement statements, so I have both to show that the requirements are complete and correct.

But.... if you do a high-level design, then that is...well... design. Who does it and/or what document it ends up in is a choice; yes, it depends on what your org wants. I think there are some factors in choosing. For example, I worked as BA where most projects were enhancements to existing systems, and external design was considered as part of the BA's deliverable. Thta was quite do-able because there was already an overall design in place, it was mainly main-frame screens and reports that were easy to moc k-up, and standards like CUA were in place. As a BA, I was not doing any original design...

At another shop, I did requirements only. Design belonged to the designer/developers. Most projects were still enhancements, but the system had a GUI interface within a browser, and we had no mock-up tools for that environment, so BAs did no design. So, the customer would OK my requirements, then the designer could design with dirrect reference as to which parts of the design satisfied which requirement(s).

I am sure there are other variations. I have used prototyping to do requirements work, showing the business what a system might do in order to make sure we captured all things the system had to do; that's a slippery slope, of course, because a real design might look different for very good reasons. What I would actually do more often is "white-board prototyping", just draw a rough screen or window on a board for discussion purposes, and then erase it when done. You get the requirements with no design artifact left over.

 

Good discussion/topic overall. You would thing we would get tired of these issues, but we never do!

 


David Wright
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Will the real Functional Specification please stand up?

Community Blog - Latest Posts

m_anst
m_anst
What Does Success Look Like? I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescripti...
0 Responses
Mariya Kotsupalova
Mariya Kotsupalova
They say the best criteria of Business Analyst’s success are a happy customer (business) and a happy engineering team. But what does it mean? How can we break down happiness and measure it? These are precisely the questions my 8 BAs team and I tried to answer this year. The result was a surprisingly efficient pair of surveys we developed and ...
0 Responses
Rajesh-N
Rajesh-N
Explore the Benefits of RPA's Adoption Across Segments In the past few years, we have seen steady growth in Robotic Process Automation (RPA). It gathered momentum in 2019 and became a hot topic in IT and business circuits in 2020. The power of process automation will be felt even more strongly, propelling its adoption as a replacement f...
0 Responses






Copyright 2006-2020 by Modern Analyst Media LLC