Skip to main content

Tag: Tips

The Top 5 Mistakes in Requirements Practices and Documentation

FEATUREMay29thIn my work with dozens of organizations improving business analysis practices, the following are the most common themes I see hindering the great value that good business analysis practices can provide.

1) Lack of collaboration and review of requirements

Collaboration and review of requirements should be an ongoing process of meeting, discovering, and collaborating to share information and context. Verifying that requirements met the needs of others to guide further work and validating that the requirements will add value to the business are critical pieces to this review and collaboration.

The mistakes I typically see in this area are teams that “gather” and “collect” requirements from stakeholders rather than using proven successful elicitation, discovery, and validation techniques. Following a “gather” and “collect” mindset sets a team up to jump to the solution too quickly before truly understanding the business needs and value required by the stakeholders.

The BA is often assigned to the project after business needs and values have already been discussed and the stakeholders pressure the BA to just move forward. This is the most important time for a BA to use powerful collaboration techniques that help the stakeholders feel that they are not restating the same information but are improving the business value proposition the project is set out to achieve.

Some teams see requirements reviews as sufficient collaboration. With requirements reviews I often see the following:
• Lack of review
• Reviewed, but missing critical stakeholders and consumers of requirements
• Reviewed but as a formality, and stakeholders struggle to truly understand requirements documentation

Ideally for requirements reviews to be successful, those using and signing off on requirements need to be fully engaged in reviewing requirements, verifying they are understandable, cohesive, and usable for the further work to be done, and validating the business value and intent of the requirements. To achieve this, BAs need to ensure that documents are presented and communicated in ways that are understandable to all audiences and the review process engages all audiences to fully participate in the review.

2) Not differentiating between capabilities, rules, project tasks, and design

Many requirements documents that I see in a large number and variety of organizations are missing the essence of what requirements are. The mistake I see is requirements documents lifting project tasks, detailed technical design, and business rules without listing the context and capabilities needed. This sets the project and solution up for a multitude of missed requirements and missed value to stakeholders. Business and solution requirements are capabilities needed by a solution to achieve a desired change in the business. They are not project tasks lists, technical design details, or bullet lists of business logic. Focusing on the true requirements instead of the project tasks and design will shorten the requirements timeline.

Project tasks need to be in a project plan of some sort, and design should be happening progressively as requirements are discovered and must account for feasibility and alternatives. Design needs to be differentiated from what the requirements are, and this can occur in a separate document or not, but it needs to be differentiated. It is no fun to manage requirements change when the requirements document is really tasks and design; this will cause more change management administration than needed. Requirements change becomes much more manageable when it is truly business and solution requirements that are changing. Changing design details and project tasks is likely to happen with more frequency and may not impact the end result, and a failure to differentiate can cause costly rework and unneeded administrative tasks.

Business rules are critical to successful requirements, but I often see requirements only in the context of business rules, and sometimes up to 90% of a requirements document is a listing of business rules. Business rules listings without the context of processes, people, data definitions, sets, projects up for missed requirements, inefficient and inconsistent implementation of business rules. Understanding the business rule outside of technology enablement is crucial to improving the consistency and efficiency of business rules. Differentiating business rules from requirements is critical to understanding and analyzing the capabilities needed to implement the rules.

3) Lack of context and visuals

Context and visuals provide our requirements readers with brain candy. Many studies show that visuals are consumed by the brain much faster than text and help depict relationships, whereas text is processed in a more linear fashion in our brains. Cognitively, visuals are proven to be more effective than text at increasing a reader’s comprehension and retention. On the other side, visuals without text can be too ambiguous. So, why do so many requirements documents lack visuals and context that would help readers comprehend and retain the very information BAs are asking them to approve? As Bas, visuals are sometimes present but often are too complex to engage our readers and need to be simplified. Sometimes our visuals as BAs are design oriented rather than intended to help readers understand context, interactions, and relationships.

Great requirements are documented in a way that allows the reader to choose the level of detail they would like to consume, provide visuals and context of varying levels of detail needed to guide further work, and provide text that clearly traces the visual and context representing the text.

4) Too much focus on the as-is current state

Projects and business analysis work is about changing the way organizations operate. It amazes me how much time is spent on documenting the as-is; I am not advocating ignoring the as-is or current state, because it is needed to understand the gaps that must be crossed to get to the future desired state. The challenge and mistake I see teams making is never getting to defining the gaps and future state. And, sometimes all of the context and visuals are about the current state with nothing showing the context or visuals for the future state.
Our requirements need to understand the current state, but the requirements themselves should represent the gaps and future state. We are not asking our stakeholders to approve the current state. Instead, they are asking us to help them change, hence we need to define the future state. Our requirements need to answer the questions: Why are we spending money on this solution? What value will the solution bring?

There are many statistics out there about the percentage of functionality in current systems that is not used; the numbers typically range between 60-80%. This raises the question of why we would document requirements for the future the way the system works today when 60-80% is not even used today? After all, today’s system was likely designed 10, 20, or even 30 years ago and we can’t possibly compete in todays business environment by developing solutions based on functionality designed for business years ago. After all, how will this take the organization into the future?

Great requirements practices and documents show how the current state is going to change, what the future state is, and the gaps to get there. There are many areas of solutions where the current rules, process, and technology will be leveraged in the future state, and this is where we need to ensure we are focused on the future by defining what pieces will move forward, and we shouldn’t spend too much effort on current state items that will not carry forward. This is done by identifying the current state at a higher level and questioning if this piece will continue to add value in the future state vision. At that point, a BA should only go into details if the value is justified.

5) Allocating requirements too early to the applications they will be implemented in

When evaluating business analysis practices and how they align with software development processes, I often see that the requirements are being allocated to software applications before the requirement itself has much context or elaboration. Understanding the requirement and business need is needed before we can specify what system or application will be changed or built to implement the requirement. The practice of assigning the technology to a requirement before the BA is assigned or before the requirement is vetted defeats the purpose of business analysis in many ways. This practice also makes requirements change a huge challenge. As we discover and elaborate requirements, we often find that the initial idea on implementation is not feasible or optimal. If the requirements process has already allocated the requirement, it takes a change request to change that in some organizations. This is where the process hinders good business analysis. Many times this practice is not in the control of a BA, but I do believe that a BA can collaborate with others, and elicit and document requirements in a technology-agnostic manner to facilitate the discovery of other ways to implement requirements.

Great requirements practices focus on the user, process, rules, events, data, and non-functional needs before deciding which exact implementation technology will be used. This allows the team to discover the true business need and explore options and alternatives that may not have been previously thought of. It also helps ensure feasibility prior to committing to a specific solution design.

Let me know your thoughts on the common mistakes in requirements practices and your challenges in these areas.

Don’t forget to leave your comments below.

The Top 10 Business Analysis Skills for 2012

I like to think of the BA role as a broker of information, getting big picture and details from many different people, groups, executives, subject matter experts, vendors, technical resources, etc . . .

what the BA does with all this information and how it gets communicated and repurposed for each audience is opportunity for a BA.

Today’s trends are pointing towards the following themes for BAs:
– Business Agility
– Innovation
– Engagement of stakeholders to drive agility and innovation

The needed skills to meet these trends in 2012:

1) Conceptual Modeling Skills
Engage your stakeholders with more meaningful dialog!  Conceptual Modeling of the business view of the solution has always been a critical tool to help bring business, technology, and delivery groups together in defining solution scope.  I have had many BAs tell me that they do this and show me their conceptual models.  What I find when reviewing the models is more of a technical architecture or data context diagrams.  Technical architecture and data context diagrams have their place, but the critical skill I am seeing as a gap in BA skill sets is the business view (vs. technical view) of the solution scope, this will be critical to engaging stakeholders and setting the stage for innovation

2) Communicating Details and Concepts
Similar to the conceptual modeling skills is communicating various levels of detail appropriate to the audience.  This can be especially difficult when you have various stakeholder needs on the team or in the meeting, and many times multiple views is needed to ensure the right message is communicated to all audience needs.  Where I see the gap today is details are not organized to be digestible and understandable to many audiences and there may be a lack of conceptual and context to accompany the details.  Without the concept and context information, the details – even when well organized – may not be understood or thought of in with the frame of mind that the BA needs from the stakeholders.  Rethink requirements packaging, does the same document need to go out to everyone?  Or, can each audience be given a guide as to which pages/sections are most pertinent to them?  Just a few ideas to help stakeholders consume what is important to them.

3) Curiosity
How curious are you as a BA?  This has always been a critical skill for BAs.   Ensuring curiosity in finding the root cause of the problem or opportunity, getting the  right audience, usage, context, purpose for requirements requires a strong level of curiosity in BA work.  Curiosity will go far in 2012 for BAs wanting to build competency and skills in the world of mobile apps, cloud computing, and continuing agile trends.  Curiosity will make some of the unknowns of today easier to work within, a curious mindset will take BAs into communicating the unknown and help organizations innovate.

4) Decomposing the Abstract into Details
I have to call this out separately from Conceptual Modeling and Communicating Details and Concepts.  The same themes are in play, but yet executed a bit differently and in different scenarios.  Decomposing the abstract into details is also referred to as “critical thinking” and sometimes “system thinking”; taking something large, ambiguous, and abstract and breaking into smaller pieces, patterns, and views.  It is about helping others see the details and big picture from different perspectives, helping stakeholders with varying points of view and priorities see where their details and others fit into the bigger picture.  It will also help BAs better estimate and work with PMs on the status and risk of requirements.

5) Mentoring and Coaching
As the BA role becomes increasingly more valued in organizations, two things will happen:  1) Organizations will need a career path for Sr. BAs, and 2) Organizations will need to develop internal strategies to develop more talent in the BA role and Sr. level skill set.  Mentoring and coaching skills are key for Sr. BAs in both of these strategies.  Mentoring and coaching done by Sr. BAs will develop leadership competencies in the Sr. BAs while developing BA competencies in new or more inexperienced BAs in the organization.  Sr. BAs who have the opportunity to mentor and coach will develop further leadership competencies needed to elevate the competencies of the BA team as a whole.

6) Communicating Risks
Project Managers focus on risks to the project budget, schedule and scope.  A BA needs to focus on risks to the business value of the solution and communicating the risk.  BAs are in a prime position to see the details and big picture view; this includes seeing the risks to the project, delivering a solution that does not maximize business value.  I find that BAs have an intuitive sense of this, but often struggle to communicate the risk in a way that gets leadership attention.  In order to get leadership attention to the business value at risk, BAs will need to develop skills in communicating the true business impact of the risk.  This means going beyond communicating in terms of the features and functionalities of the process or software, and going beyond that, there is not enough time for requirements to be done right. It means communicating the impact it will have on the business operation or strategy.  For example, when the functionality of a point of sale application has a requirements conflict in the process of accepting payment from customers, the focus needs to turn to the impact of the conflict on the customer service representative’s ability to serve the customers and the customer experience vs. the technical details at risk of the requirement.  In the heat of requirements and design details, we often let the details drive risk discussions and never get to the bottom line impacts that can really propel leaders to make the right decisions.

 

7) Leveraging the “parking lot”
Are you running your meetings or are meetings and stakeholders running you?  Many BAs get into tough situations in requirements meetings and feel that other agendas and personalities are driving their meetings astray.  Using a “parking lot” (simple visual list of items that do not fit into the meeting agenda to be followed up on or scheduled into another meeting) to manage and control the meeting agenda, content, level of detail and difficult personalities is a key strategy.  Most importantly, make sure that the parking lot is visible to everyone in the meeting.  Having the parking lot in your notebook or on your laptop does not show others that you have their ideas and concerns captured to discuss at a later time.  Be empowered to take control of your meetings!

 

8) Change Management
Embracing the BA role as an agent of change will continue to show the value the organization the value the BA role brings to the organization. Projects are about business change; the BA role is about bringing the most value possible in a solution to address the business change.  The role of a change agent in the BA is critical to ensuring all impacted parties are ready for the changes needed to accept the solution.  Understanding how changes and solutions impact the stakeholders operations, processes, attitudes and behaviors is a key skill in maximizing the success of the new solution and the business value it brings.

9) Asking WHY?
I love the word “Why”, but hate to use it.  My challenge to readers of this blog is to help one another find ways to ask “Why”.  Many times using the word “Why” can come across wrong to the other person, it can seem defensive and the other may wonder why (no pun intended) you are asking.  Finding different ways to ask “why” can alleviate this dilemma.  My favorite ways to ask “Why?”:  Tell me more about what is behind the need for abc?  What does success look like?  What would happen if this project does not get implemented? What are yours?

10) Impromptu Whiteboard Drawing
In 2012 when innovation, agility, and engagement are the trends, being able to spontaneously draw will lead to stakeholders to a deeper level of engagement.  Getting up to draw shakes up the flow of boring meetings, engages others to focus back in on the discussion, and brings out humor – let humor be a friend. You don’t have to be an artist to draw concepts on whiteboards that generate great dialog, discussion, creativity and innovation.  It also does not have to be you that does the drawing; ask someone else to draw what they are thinking and your meeting will benefit in many of the same ways.  When the drawing yields powerful and meaningful discussion, be sure someone takes a picture with their phone.

No matter that type of BA, no matter what the industry, these skills in 2012 will set your projects up for deeper engagement, innovation and agility.

Don’t forget to leave your comments below


 

The Structure of Business Analysis Documents

The structure of business analysis documents isn’t a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.

These are the main documents produced by a BA over the course of a project:

  • Current state analysis document
  • Project vision document
  • Solution vision document
  • Business requirements document
  • Business process design document
  • Use case model document
  • Use case specification document
  • System-wide requirements document
  • Solution glossary

 

The diagram below shows the attributes common to all documents:

 

Korban Diagram01 08 05 2012

Current State Analysis

Once a project has been mandated and the Project Initiation document (PID) is drafted, a business analyst can start to work on requirements gathering. In my experience the best way to tackle this task is to start from current state analysis. It helps understand the business need, primary pain points, business processes affected, the stakeholders involved in these processes, and so on.

The area of the current state analysis is illustrated below:

Korban Diagram02 08 05 2012

The main purpose of the analysis is to present the “AS IS” state: the existing business context, background, business functions and existing business processes, and finally stakeholders involved in these business processes. Depending on the project nature, some components of the underlying infrastructure can be included in the document as well.

A Current State Analysis document lists the key pain points within the identified business processes and tasks within them, and highlights the areas where a change is expected.

The last section of the document is about presenting recommendations. It recaps the key findings and lists the key changes expected. Any caveats should be presented here as well.

The content structure of the Current State Analysis document is presented below:

Korban Diagram03 08 05 2012

This document serves as a foundation or a reference point for other artifacts produced by a business analyst. The other documents will be discussed in the following articles.

Project Vision

The Project Vision is a document which is shared by a project manager and business analyst. They work together to outline the problem statement, determine the desired state, describe the criteria of business acceptance of the deliverables and how project success will be measured. The document contains a section with stakeholder analysis which shows all the parties involved along with their responsibilities and needs:

Korban Diagram4 08 05 2012

The business analyst adds the high level requirements which are within the scope of the project, and marks each requirement as compulsory or optional. To clearly define the project scope and avoid ambiguity, all out-of-scope requirements are also listed at the end of the section.

Based on the results of the current state analysis the business analyst describes the current business context, the key business processes and services used to support them. After that the required changes are mapped to the current business context. It can be a good idea to present this mapping as a diagram for easy communication of the proposed changes to the business stakeholders.

Solution Vision

Once the Project Vision document is approved, the preparation of the Solution Vision document starts.

Korban Diagram05 08 05 2012

First, the business analyst recaps the problem statement from the Project Vision artifact. The solution statement describes the target audience of the solution, what will be satisfied by the solution and what the key benefits will be. The statement of differentiation of the solution from possible alternative options is added as a conclusive point in positioning of the solution.

The document describes stakeholders within the target audience along with their roles using a RACI matrix.

The main part of a Solution Vision is a detailed section devoted to the solution capabilities comprised of both functional and non-functional features, with priorities given by the business stakeholders.

The next section presents the business context in its future “to be” state. It’s a good idea to include a a diagram illustrating the key changes and additions to the existing state, as well as a brief narrative to clarify the proposed changes.

Similarly to the Project Vision document, the features that are out of scope are clearly listedin the last section to make sure everyone is on the same page with regards to what will be implemented.

Business Requirements

This document focuses on providing details about the current processes and gives enough information to describe the business problem and how it fits into the scope of the project. This section reiterates the findings of the Current State Analysis document, however here they are aligned with the project objectives.

Korban Diagram6 08 05 2012

The business requirements that are going to be fulfilled by the solution are listed in the “In Scope” section. Business rules that apply to the described requirements are presented in a separate section. This approach simplifies the confirmation of the rules with business stakeholders. 
Any assumptions and dependencies identified in relation to the business requirements are to be listed in the appropriate section.
The proposed changes to stakeholder roles, new or modified business processes and business services that support them are presented in the last section.

Business Process Design

This document focuses on the scope of changes to business processes, providing details about the current business context, existing business processes, and stakeholders involved in these business processes.

Korban Diagram7 08 05 2012

It also describes the future state: the proposed business processes and the “to be” information environment. The new processes are accompanied with narratives to facilitate communication of the proposed changes to stakeholders and business end users. This “as is” section reiterates the findings of the Current State Analysis document, however here they are aligned with the changes to supporting business services.
Any assumptions and dependencies identified in relation to changes to the business processes are listed in the appropriate section.

Use Case Model

The Use Case Model lists all the scenarios for using the solution required by the business stakeholders. It is useful to describe the solution as a set of functional areas and group the scenarios per functional area. Such an approach allows to use this document more efficiently in communication with the business stakeholders as they can easily refer to the sections of their interest.

Korban Diagram08 08 05 2012

The model lists all possible scenarios in scope, their brief summary, actors involved in each scenario, frequency of use, triggering events and the two possible outcomes – success and failure.
One of the key attributes of the scenarios is a reference to the high-level requirements and required capabilities which allows to establish traceability.
Note: when making changes to Use Case Specifications, do not forget to update the Use Case Model document accordingly.

Use Case Specification

A Use Case Specification document presents more detailed information about the use cases in the Use Case Model document.

Korban Diagram09 08 05 2012

Each specification includes:

  • Brief use case overview
  • Reference to the functional area
  • Preconditions
  • Actors involved
  • Main flow
  • Alternative flows
  • Exception handling flows
  • Functional requirements for the solution
  • Traceability to the business requirements
  • Market or business rules applicable to the scenario
  • User interface, controls and data

System-Wide Requirements

This document is prepared when the Business Requirements, Use Case Model and Use Case Specifications are complete. The main purpose of the document is to present a “qualitative” side of the solution.

Korban Diagram10 08-05-2012

The “Load patterns” section is the most interesting as it illustrates how the solution is expected to be used during a business day. This information gives good insight into business requirements from the “non-functional” perspective and helps clarify the business requirements where required.As solutions are often based on information technology, some attention should be given to solution resilience. Disaster mitigation approaches and solution recovery requirements play a major role here.It is a rare case nowadays that a solution is completely new. The common practice is to integrate the solution into the existing business environment. The system-wide requirements document describes the interfaces with internal and external systems and solutions, the data flowing between them, its formats and data elements. Where the solution should interface with external systems, samples of data must be presented in appendices.Apart from business reporting capabilities, the solution must provide reporting capabilities for monitoring how the solution operates. These reports are listed in the last section of the document.

Solution Glossary

Business stakeholders often use terms and jargon in their communication. To get up to speed with this terminology (you can be quite new to it), the Solution Glossary document is used. It helps establish common terminology for the project team and key stakeholders, and for use within the solution. The structure of this document is simple:

Korban Diagram11 08 05 2012

It’s a good practice to divide the solution into functional areas. These functional areas serve as small knowledge domains for the stakeholders involved in the project. This document serves as a reference point for all the previously discussed documents.

Don’t forget to add your comments below.

The Best Virtual Meeting…EVER! Five Fun Games to Engage Your Virtual Project Group!

Do you ever have those days when go you off on philosophical tangents? You know, those cold, gloomy mornings when you stare out the window, coffee mug in hand, wondering, “Does a fish know what water is?”, “Is the colour red really universal?” or “Is Robert from marketing a real person?”

We’ve all been there. The truth is it’s hard for virtual project groups to bond on a personal level with other group members…partly (well, mostly) because we may not even know what the other person looks like! Without bonding, the results could be dangerous. The University of California, San Francisco, lists some of the common symptoms of a disengaged team:

  • Decreased productivity
  • Conflicts or hostility among staff members
  • Confusion about assignments, missed signals and unclear relationships
  • Decisions misunderstood or not carried through properly
  • Apathy and lack of involvement

And there’s more:

  • Lack of initiation, imagination, innovation; routine actions taken for solving complex problems
  • Complaints of discrimination or favouritism
  • Ineffective staff meetings, low participation, minimally effective decisions
  • Negative reactions to the manager
  • Complaints about quality of service

And there’s still more! A 2009 article from the Occupational and Environmental Medicine showed that a lack of team spirit can even cause employee depression…But don’t panic!

Before you scurry off to Google, furiously searching “how to engage virtual project groups” — take a breath. We’ve done the work for you. Here are some innovative games that are sure to have your team amused and engaged in no time.

1) Virtual Charades – Charades is a great game that builds group spirit, whether in a traditional workplace or a virtual one. If your company usually sets up video conferences for meetings, this is definitely a game that will have everyone working together, solving problems and having fun along the way. If you’re unfamiliar with the game, Charades requires the player to mime or imitate a certain action or subject that the rest of the team has to figure out. For more information on how to play, click here .

For those who use voice chat instead of video chat, there’s a fun alternative for you too — Voice Charades. For Voice Charades, create a secret list of objects, animals or famous people. To decide who will go first, enter all team member names onto a site such as Random.org and choose the first name that shows up. Email or send an individual/private instant message to this team member letting them know what they will be acting out. Remember to keep the clues work-appropriate and respectful of others. Have fun guessing what/who the person is imitating. Some entertaining suggestions are:

  • Printer sound
  • Al Pacino impersonation
  • Star Wars Light saber
  • Monday traffic
  • Radio anchorman

2) Spin a Tale – This fun game fosters creativity and helps team members think on their feet. During a meeting, make up the first line of a story. Then ask team members to take turns and add each subsequent line until a whole plot develops! Let the story go along on its own path and deviations. This is the fun part of the game; you never know what perils or fortunes can occur next! The best thing is, even though your team may develop favourite start tags, the story will never end up the same! In other words, you learn how to think innovatively. Here are some ways you can start your tale:

  • I woke up at 9am — that was when we were supposed to Skype in for the meeting…
  • Jared looked over the ledge of his balcony, wondering why the crowd had gathered…
  • The email had no subject line…I hate it when he does that…
  • Fifteen years, 15 days, 15 hours and finally the letter had come…
  • As Sophia hid behind the red SUV in the parking lot, she tried to remember how exactly she had gotten there…and why there was that giant scar on her arm…

3) Situation Puzzles Situation puzzles are an exciting way to exercise creative problem-solving skills while also building team unity. In a situation puzzle, the team leader states one mysterious sentence such as, “a bell rings, a man dies, a bell rings”.* The rest of the team must now solve the situation by asking “Yes” or “No” questions. As each question unearths new information, the team can creatively build on each other’s thought patterns and ideas until all the loose ends are tied. A great reservoir of situation puzzles can be found here!   *(Click here for the answer)

4) PowerPoint Game  You will never look at PowerPoint presentations in the same light after this game! This is a great way to get group members thinking on their feet while having loads of fun. To play the PowerPoint game, go online and find a series of complicated or extremely nonsensical PowerPoint presentations (try SlideShare). Then ask team members to improvise a presentation with the slides they’re using. Hilarity is bound to ensue! Go here for more information about the PowerPoint game.

5) 2-Minute LOL  This is another improvisation game that will get everyone thinking fast, learning about team members and literally laughing out loud. First, divide the team into smaller groups or partners. Then give each group a topic or let them choose one. Allow each team about five to ten minutes to create a set of jokes based on their topic. Make sure they have this discussion in a separate virtual conversation so that the rest of the team does not hear the punch lines beforehand. When everyone regroups, randomly choose a group to go first while timing their comedy improvisation for two minutes. Once again, remember to keep all jokes respectful and workplace-appropriate. Award the funniest team with a gift card or some other form of prize!

And there you have it — five amazing ways to engage your virtual project group! Try them out and let us know which game your team liked the best! And if five tips aren’t enough, here’s a whole book full of tipsAcross the Hall, Around the World is the ultimate archive of virtual team-building tips that’s sure to get your team engaged!

Don’t forget to leave your comments below.


Claire Sookman is the driving force behind Virtual Team Builders, Claire brings to the table over a decade’s worth of corporate and public sector training experience, working with over 4,500 managers in the past three years. Specializing in virtual team building and communication strategies, Virtual Team Builders provides training that enables global teams to work more efficiently.

Requirements for the App – Tips and Tricks for the iPad World

Tablets are omnipotent these days. They have revolutionized the way we do a lot of things. App developers are in high demand and businesses with a product are jumping over themselves trying to get ahead in the game by establishing a presence through offering an app. The recent slew of customers that approached us for requirements related to an app offering got me thinking of how doing requirements engineering for an app is different from a regular product and what key things you should bear in mind as you develop your app.

It’s all about the look

What makes an app on a table device cool is that the graphics are slick and somehow makes the person using the app feel tech-savvy in the process. Like it or not, the “cool” factor for a user interface is one of the things any app is rated on. My advice is to not take this area lightly, but rather to invest in user design experts whose work you have access to and appreciate. Ensure the process is creative and collaborative.

Tip: In order to contribute as a BA, explore various leading apps in the same domain or targeted at a similar audience in order to find out what you like, what’s popular and what suits your app perfectly.

The sense of touch

Tablets are typically devices with touch screens, so your app will have to respond to touch events well. This can open up an entirely new dimension of engaging with the user. The level of satisfaction a user derives from a well-performed task in response to an intuitive action can be very high and almost addictive, and can encourage usage of the device and app frequently. Innovation can be key in this area as well – the iPad started a revolution simply by tapping the potential of this aspect of interaction with the user.

Tip: Mimic the actions you would perform where applicable. For example, flipping a whiteboard to get to the next page, or for a charting tool, pulling a pie slice out to see what the rest of the chart looks like without it. Then, ensure your user interface responds to such motions.

Give something back quickly

While we are using tablets more and more for certain tasks, not everything has changed. Recent surveys of tablet usage [1] show that while we use tablets more for tasks such as listening to music, downloading, maps and information when we’re on the go, we continue to prefer our desktops for activities that require extended periods of attention. A lot of work therefore continues to happen on desktops and laptops. Given this nature of usage, a good principle to follow is to give something back to the user quickly.

Trick: If your app is helping someone plan their finances, make realistic assumptions based on some key data to show them projections quickly in order to demonstrate the capability and value of your app. Then give them the opportunity to fine-tune the accuracy of projections by entering their data for better results. Once users can see what your app can do, they will take the time to enter data as they know what they will get in return.

Scope

Organizations are rushing frantically to put an app version of their product “out there” and establish a presence in the mobile space. But the problem is that when you have an existing product or solution, you can’t really take it in its entirety and “app it.” You typically should consider reusing components and bear in mind the overall goal of the solution, but feel free to make the app different where it needs to be in order to fall in the category of a well-thought of and useful app.

Tip: A good exercise to carry out is to study the scope of the existing solution that’s available and prioritize what is necessary and what can be forfeited. Your app should have functionality that’s absolutely vital but can leave out the bits and bobs that are incidental.

Keep your app light

Keep your app light. Reuse components from an existing app by making them available as online services. Avoid unnecessary data capture. However, if your app needs to function as a standalone app, balance the need to keep it light with its need to be functional in a disconnected mode.

Tip: Explore non-functional requirements related to app development to ensure all aspects of the app are covered.

Be aware of app guidelines

Lastly, be aware of the limitations and guidelines for your app. While most leading target operating systems (Android, Blackberry, Nokia’s Symbian operating system) don’t proactively publish guidelines before putting an app on their store, Apple has stringent guideline [2] and your app will have to go through a two-week approval process before it is made available on the App Store. However, even for apps targeted at operating systems other than iOS, the guidelines on Apple’s website are a great read to help you develop a good app.

Trick: Go through the guidelines on the Apple website for pointers on your app.

Conclusion

With all of that said, requirements for apps are exciting and a brilliant learning opportunity. The aspects I’ve put forward in this article are an excellent starting point but there’s lots to discover along the way. I wish you all the very best for putting together your app – happy discovering!

Don’t forget to leave your comments below. 


[1] BusinessInsider.com, TechRadar.com 
[2] Apple app guidelines can be found at https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html 


Remzil Kulkarni has over 15 years of experience in technology enabled business transformation focused on Insurance, Telecom and Finance. She has a Masters degree in Engineering Management from Southern Methodist University, Dallas TX and is President of the IIBA Pune Chapter. She is a certified Prince2TM Practitioner and a Fellow of LOMA (FLMI). She currently heads the Business Analysis Centre of Excellence at Mastek Ltd., where she has worked for the last 6 years.