Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  What vs. How
Previous Previous
 
Next Next
New Post 11/7/2009 10:32 AM
User is offline jea99
3 posts
No Ranking


What vs. How 

If you ask a business analyst the difference between analysis and
design or the difference between business requirements and solution
requirements you will, in all likelihood, hear about “what” verses
“how”.  However, I have found that, in practice, this distinction is
not as clear as we often assume.  One person’s “what” is another
person’s “how”.  I would like to hear from the group on what criteria
you use to distinguish “what” from “how”.
 

 
New Post 11/8/2009 3:09 AM
User is offline bas
21 posts
www.uml2.ru
9th Level Poster


Re: What vs. How 
I like divide reqs by 3 words: * why (we built System - BR) * what (System should do - SR or user want from System - UR) * how (System will process "what" - DR) Analyst should concentrate on what (System should do - SR or user want from System - UR). But some time can detail it by using how (System will work). You can understand the distinction if you ask about each req - is it what system should do or is it how system work.
 
New Post 11/8/2009 6:43 PM
User is offline jea99
3 posts
No Ranking


Re: What vs. How 

 

 
Thanks for the post but I have some problems with your very sensible suggestions. 
 
First, requirements do not answer the question why.  This is more the stuff of mission statements.  Second, I find words like Why-What-How are subjective. Consider the requirement “The system must maintain Contact information”. Is this what or how? It is “what” in the sense that it does not give you much detail on how information will be maintained.  But is “how” in that it states that information is organized around the idea of a Contact entity of some sort. All we can say is that it seems to be more “what” than “how” but we are in a gray area here. The sad truth is that there is a what-how continuum here.  Not binary. 
 
I have a proposed solution to this problem but will save it for a later post. 
 
Again thanks for taking the time to help me sort this out. 
 
New Post 11/9/2009 1:17 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: What vs. How 

I think it always helps to attach the why to a requirement.  In several instances I have tagged each requirement with a driver, pulled from either the organisation;s scorecard or from the project charter or business case.

Examples:

1. Call centre staff average handle time must not increase due to complex or difficult system interfaces - drivers; keeping costs down, standard user experiences with systems, standard customer experiences.

2. Automate a manual payments report; drivers - ensure the job is carried out at a cnsistent time, ensure that the report doesn't get 'crowded out' by other work, ensure the report is produced in a consistent format over time

3. Put the order form on the website - drivers - cost mangaemnet, 24 customer access, drive out data quality issues

These are three simplistic examples.

Also take a look at the User Story format of requirements specification.

 

Lastly, I suggest that the what, how and why of requirements is less of a sliding scale and more of a series of concentric circles.  You peel layers back, as you drill in, and each time the immediate context changes from one to the next.

 

 
New Post 11/23/2009 7:56 AM
User is offline KIERANC
22 posts
9th Level Poster




Re: What vs. How 

Requirements need to be specified in enough detail so that everyone can agree that they constitute a basis for development. Often time a single Requirements Specification can be produced covering both the business project and the Technology Project(s) supporting it. To ensure that agreement is there the requirements must be Testable and Prioritised - using MoSCoW Rules etc and Traceable.

The Business Functional Requirements will specify

What the solution is expected to do in order to meet the anticipated benefits

What are the validation requirements for the data being entered etc.

The Non Functional Requirements will cover

What are the Application/ system operational requirements

What volumes of data and voice transactions are involved for this process?

What are the Support / maintenance / technology environmental requirements?

The Infrastructure Requirements will cover

What security controls are needed to support the system or application usage? What are the logistical requirements? What are the Communications Requirements. What are the mainframe requirements? What Business volumes are anticipated? What are the service requirements? What are the training requirements. What are the testing / implementation requirements?

The Functional Specification will then state HOW these requirements can be met. The FS will consist of process and data models which together make up the application model and provide an unambiguous description of how the system will meet the requirements that should be understood by both users and Technology alike. The Application Model will normally consist of an Application Process Model which could consist of Use Cases or functional decomposition models using Data Flow Diagrams and Elementary Function Descriptions, etc.

The main thing is that the Functional Specification supports the business objectives and requirements as defined in the Requirements Specification. It is an iterative process and as Craig says is very much like peeling back concentric circles. Tagging a why to each requirement makes a lot of sense in this context.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  What vs. How

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC