Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Mock Ups and Requirements.
Previous Previous
 
Next Next
New Post 8/26/2010 4:12 AM
User is offline Lena
14 posts
10th Level Poster


Mock Ups and Requirements. 

Hi,

I'm working for a small agile business as a Requirements Analyst.

I was initially hired to implement the Requirements Process and specialise in the traditional requirements elicitaion techniques and producing Requirements Specification.

Our new IT Director is planning to introduce Mock Ups as a predevelopment source and use them instead of formal requirements specification. It sounds very odd to me although cannot contradict my boss.

Has anybody of you had the experience of using Mock Ups in the agile ( sprint/scrum development) and your ideas on them.

Thank you!

 

Kind regards,

 

Lena

 

 

 

 
New Post 8/27/2010 6:36 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Mock Ups and Requirements.Hi Lena, 

Hi Lena,

I've never worked on a 'pure' agile project, whatever that is, so there are probably others in the forum with better answers. What I have done is see agile done badly i.e. as an excuse to skip steps and get straight to building screens.

It seems to me that before you get to the stage of mockups you need to at least have a list of the functionality you want you system to support. I'd do that by listing what use cases I need perhaps with a description of what the funcitonality in the use case is without actually defining the use case. You then have your scope nailed down - this is the important piece to get understood by everyone. From there you can start mockups and work out your business rules, validations, data, etc with the business users as you go.

Agile talks about user stories which I think are just what I've described in broad terms. Going straight to mockups without taking the time to do this means you'll more than likely fail IMO. Buy a book or check on the web to get more information on user stories.

Kimbo

 

 
New Post 8/27/2010 7:51 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Mock Ups and Requirements.Hi Lena, 

 

I have had a few experiences with discovering requirements that will be provided to an Agile development team. Working with their lead people, we came to the conclusion that a step or group of steps within a use case can be used to define User Stories. So, integration is possible...


David Wright
 
New Post 8/27/2010 9:06 AM
User is offline Chris Adams
323 posts
5th Level Poster






Re: Mock Ups and Requirements. 
Modified By Chris Adams  on 8/27/2010 11:16:01 AM)

Lena,

In my experience, mockups can support the requirements gathering process when introduced at the right time, but they cannot be the entire requirements gathering process.  Here are a few key points that I've raised to management and executives before regarding the pitfalls of mockups to gather requirements.

1)  Mockups are nice because they help the business representatives or client visualize the functionality, but if introduced too soon in the process the natural tendency is for the business reps/clients to try and be screen designers.  Instead of stating that the system needs to support "x", they beginning saying that they need a dropdown to capture "y" and a button to do "z".  The client is not a UI designer, in fact few business analysts truly are.  So this tends to lead to a mess of an application.  Similarly it detracts from the true requirements which aren't what should the system have in terms of controls but what NEED does the business have that must be met via the system functionality.  It just places the emphasis on all the wrong things.

2)  When requirements are captured in UI mockups with no support requirements list, later in the design and development process analysts and developers encounter problems that cause them to question why the screen must be a certain way.  "Do we really need to have this control here versus there? Does it have to be on this screen, or can we capture the data later?"  At this point, there is no way of knowing if the control or feature was placed in its current location due to a specific requirement, or if it was an arbitrary design decision at the time.  We have no idea what the actual requirement is, do we.  We also don't know how design decisions map to true business requirements.

Ultimately, I believe that the introduction of UI mockups can be very helpful, but this should occur after an exhaustive list of features and usage scenarios (what business process flows need to be supported by the system) has been documented.  Only then can the UI mockups be generated without introducing major pitfalls.

Taking this one step further, when the time is appropriate to introduce UI mockups you may also consider using a tool to generate a clickable model.  These are basically mockups that have some ability to navigate from one to another and the ability to show new controls based on certain button clikcs or control selections.  A clickable model is a powerful tool for reveal problems with UI design that have not been considered. There are a number of tool on the market which are design to to this.

I hope these reasons can help you convey to your management the dangers of using mockups for the requirements gathering process.   I would try to communicate there benefit as a form of requirements verification.

 


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 8/28/2010 7:20 PM
User is offline Anthony Chen
63 posts
8th Level Poster


Re: Mock Ups and Requirements. 

 We use mockups as a vital part of the development process.

The difficult part of using mock ups exclusively is that you become design focused and  the team doesnt have a common understanding of why things are the way they are.

Here are some items that arent covered by mockups

1) Testers arent sure how the system is supposed to behave just from mockups - what data goes into fields and what business rules get triggered behind the scenes. They also need a linear checklist to make sure that all items are covered.

2) Without use cases or process flows, how the mockups get chained together to help the user to complete a task may be unknown

3) The purpose of the system is driven by high level business objectives. Those map to functional requirements. These are not addressed at all by mockups.

4) It is impossible to control scope creep if you dont understand the core features that create the value for the system. Without those it becomes an endless stream of "I think this is really important"

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Mock Ups and Requirements.

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