Tag: requirements

  • Cost Of Business – Components of Commercial Software

    Cost Of Business – Components of Commercial Software

    One of the first items of discussion with a client that wants to build an application is cost.  When they are new to the process, the cost is a complete mystery.  The wide range of resources available does not help this.  There are low-cost offshore providers all the way up to high-cost boutique firms.  However, the largest impact on the cost of an application is scope.  There are many components to consider, with some being more or less optional.  Let’s look at the components that should be addressed in some way for any real application proposal.

    Security

    A commercial application is almost expected to be secure these days.  However, a secure system is not a guarantee of safety, focusing on taking proper steps.  Customers will often have a checklist of items they expect to be a part of a secure application.  When you design and estimate your solution, each of these items should be covered in some way, even though this may simply be a note that the feature is not needed.

    • User Login and Account Management – Nearly every application requires some login functionality and a way to manage your account and password.
    • Data Security – Many uses of data requires that the data is encrypted or otherwise secured. Even when customers are not concerned about their data, it is good to avoid being the news due to a data breach.
    • Encrypted Data Transfer – A secure web connection (HTTPS) is needed to avoid warnings when a user connects to your site.  Also, Google has now made HTTPS an important factor in being considered a good site to rank in search results.
    • Single Sign-On/Third-Party Integration – This is a corporate application where users will want to authenticate using their Active Directory account or one that is more appropriate for Facebook or Google authentication.  In any case, customers are asking for easier ways to securely authenticate to their favorite applications.
    • Vertical Data Storage – This feature is not needed for all applications, but B2B software often will look for it.  The key is to be able to ensure that they will only see a customer’s data.  A bug that exposes data to other users can be crippling, so an architecture that makes this almost impossible will help sell your solution.
    An application that is a toy or game will not need to worry about these features.  However, even a simple calendar or address book application will need to consider each of these.  A decision will then need to be made about which to include and how thorough the functionality needs to be.

    Finishing Touches

    There are several components of a commercial software application that are critical but often overlooked.  However, these do get added in late in a project as the gaps are noticed.  Unfortunately, the late addition to the project is a common reason for these items to cause cost overruns and delays.  Consider these features from the initial design, and you will be more likely to avoid such issues.
    • Logos and Branding – This is often a larger problem for web applications.  The images used within your application need to be decided on and designed or otherwise properly licensed.  This step includes things like wordsmithing your notification emails, general messaging, and content, as well as look-and-feel.  Although some environments (e.g., A Windows or Mac application) provide standards and templates for many of these issues, there are almost always gaps to fill and decisions to make.
    • Notifications, Help, and Messaging – A big part of an application’s usability is how well it communicates with the users.  This communication is done through messages, email, help options, and more.  As an application moves from a demo to production, there should be a focus on making the notifications easy to understand and keeping the user informed.
    • Documentation – Developers are not known for their love of writing.  Thus, it should be no surprise this is another component that is often missed.  Whether the requirements are for a User Manual and detailed manuals or a technical guide, this is an important piece of commercial software.  We all know that no one reads the User Guide.  However, we also know that a product without documentation is probably shoddy or bug-filled.  A lack of proper documentation can hurt sales and cause support costs to be higher than expected.
    • Packaging – Even digital products need packaging.  This packaging can be install scripts, license keys, or even physical packaging.  In all of these cases, the final product must be put together in a way that it can be shipped.  Even membership sites will need a registration and billing piece.
    I have found this group of components to be the most likely to be overlooked.  Thus, these features are often treated as a change request or “add-on” that raises the cost and delays completion.  Make sure these are accounted for in any proposal.

    Maintenance

    This next group of features pertains to infrastructure and product maintenance.  Technically they can be avoided.  However, doing so is almost always going to contribute to future headaches and high maintenance costs.  It may even become an unavoidable barrier to enhancements and upgrades.  Ignoring these features is a good way to keep your product from ever being anything except a toy.
    • Logging and Exception Handling – This is a key differentiator between a coding team and a software development team.  All software hits snags somewhere.  These can come from a nearly infinite variety of sources.  Thus, good software cannot stop exceptions but instead handles them gracefully.  Errors and exceptions are handled and logged so the developers can look to avoid the problem in the future or even fix damage caused by a bug or glitch.  This is also a piece that is challenging to shoehorn in at the end of a project.  Take this component into account from the start of the project to avoid costly surprises.
    • Database design – Most modern applications utilize a database.  However, this does not mean all databases are the same.  The architecture and design of the database should be a mini-project in itself.  Assign resources and ask questions to ensure that the database is designed to handle the expected number of users and types of data.  The size of the data is also significant.  It should be clear whether the system will be handling thousands or potentially billions of records.
    • Backups and Build Scripts – This gets into the weeds a bit.  However, a professional product should include a disaster recovery plan and backups.  There should also be build scripts, and version control used correctly.  This may not matter as much to customers, but it should be critical for owners.  Think about building a house and then losing the location and ability to enter the building.  All that work becomes worthless.  That is what can be faced when building software that does not have version control and build process or script.  You may have access to the source, but the cost of building it and bringing your application back online may be more than you can afford.
    I must agree that these components have more to do with the owner than the customer.  Nevertheless, these are all critical in producing reliable commercial software.

    Avoid Surprises

    As you can see from this list, there are a lot of factors that go into building a commercial product.  If you are considering taking on something like this, make sure you find a reputable provider.  Ask questions and look at competing products to make sure there are no holes in the requirements.  The longer it takes to find these sort of holes, the more expensive they become.  Of course, you can always contact us at RB Consulting for a free consultation to get you started in the right direction.

  • Project Success – Solving The Right Problems

    Project Success – Solving The Right Problems

    When we talk about starting a project off correctly, we often mention problems to be solved. Unfortunately, solving problems alone is not the path to success.  We must also make sure we are solving the right problems.  Luckily, this task is not challenging and just requires us to ask a few questions.

    Who Do We Ask?

    The first thing to do is to identify who speaks for the solution.  This speaker is the person or persons that will use the product.  They may be subject matter experts (SME), but more often are an end-user or a representative for the users.  These people are easy to identify because they are the ones faced with the problems we are solving.  These are the people on the front line that will be most impacted by the solution.

    For example, an accounting package may be required to have features based on the desires of the CFO.  However, the accountants using the software need to be able to enter and retrieve the data the CFO wishes.  Since the users are ultimately providing the features to the CFO, then they are the ones that will best define the problem.

    What Do We Ask?

    Once the target speakers are identified, it helps to explore their routines.  Make sure you go beyond daily routines as there are processes that only run weekly, monthly, or annually.  As they share their schedule, there are opportunities to point out pain points and struggles they have.  Ask them what they find most annoying or time-consuming in their routine.  Look for repetitive tasks that can be automated or simplified.

    Ask them how beneficial the solution is to them when the interview process is done.  List out what problems are going to be solved.  This list should get a response along the lines of “that will significantly improve my life.”  Be clear about the solutions as far as what it will, and will not, provide.  This is a critical part of setting expectations.

    Digging Deeper to Find What We Are Solving

    An important part of the interview process is digging down to the core problem.  There are problems that only exist because of the current processes.  Once you ask why something is done you might find a simpler solution.

    A favorite example I ran into (and similar to several other situations) dealt with a large report.  The solution was a web application that dealt with data on millions of objects.  The user needed a report that could bring back millions of rows almost instantly.  They were fine with a paging solution, but did not want to accept a solution where we asked for search criteria that brought back less data.

    As we dug into the goals we found out that no one actually needed all those records returned.  No shock there.  No human can consume millions of records.  They wanted the records so they could see the count of records returned.  Yes, the end solution was to provide a record count based on any search.  A single number is what was needed, not complex queries and paging solutions.

    Never Stop Learning

    The moral to this story is to understand the problems to be solved.  Do not simply have them listed and then run off to craft a solution.  Understand the “how” and “why” of the problems.  This will help you design a solution that is useful to the end user and not a complex approach that is too slow, expensive, or hard to understand.  Better yet, look for milestones where the speakers for the project can assess how the solution is going and provide feedback.  It never hurts to check your work along the way.

     

     

  • Writing Good Requirements

    Writing Good Requirements

    There is a discernable difference between novice and veteran requirement writers.  The process is more art than science, but it still has some best practices that can be of help to anyone.  Here are some points to consider that can help you make your next requirements document the best one you have written.

    Outline the Requirements

    In my experience, this is the most natural step.  Start with a high-level overview of needs for the project.  This helps set the stage for greater detail while providing a core design.  It is important to have this basic design as it provides a reference point as the details are refined that can help avoid drift.  Once this outline is created it can, and should, be regularly referenced during the definition of detailed requirements to ensure the details link back to core features.

    The highest level outline of requirements is the vision for the project.  The outline is the general view of what is to be created and drift from the vision is highly discouraged.  It does not mean the vision cannot be altered or refined.  However, a project is a plan for moving from A to B.  The B is the vision.  Therefore, changing B as the focus can create situations where you “take the scenic route” or even become hopelessly lost.

     

    Ask “Now What?”

    Once the outline comes together, it is time to go to the next level.  This point is where most requirements fall apart.  There are a set of questions that a well-defined requirement will answer.  Let’s look at each one and what to consider in answering it.

    How do I get to this point?

    This question looks at how a requirement is executed.  It includes considering who can access a feature and whether it has limits for different users or times.  For example, an ATM has a requirement to dispense money.  To receive cash, someone must be authenticated to the system (card and PIN).  An authenticated user has made a request for withdrawal.  The account has been selected, and it has a balance greater than the sum to dispense.  Keep this example in mind as we look at the other questions.

    What data should I have once I get to this requirement?

    This question addresses the state or environment we can expect while fulfilling a need.  It potentially includes defining how the data is gathered in the first place.  Thus, we might find some more requirements to be determined while answering this question.  In the above ATM example, we should have an account number, an authenticated flag and an amount to withdraw.  Thus, we should have requirements defined that address how an account number is gathered, how to mark a user as authenticated, and how to tell the system what to withdraw.

    What is the expectation when this requirement is fulfilled?

    At this point, we define what success means for the requirement.  If we can not determine success or failure of a requirement, then it is either not needed or ill-defined.  For example, an ATM withdrawal results in cash dispensed and an account debited.  There may be new expectations as well, but they should all be defined as part of answering this question.

    Where do I go from this requirement?

    The first question we asked is the entry to this requirement.  This question is the exit.  Once a requirement is fulfilled, we need to examine the options for proceeding.  Often the answer to this issue is a list of “locations” based on success or failure.  In the ATM example, we will show a success message, an error screen, or might go back to the main menu.  This step is where we might turn up some other entry requirements to define.  For example, is there a “quick cash” option that skips going back to the main menu and instead logs the user out after dispensing cash?  Alternately, is there an optional “print receipt” step to consider?

    What happens if an error occurs?

    This is the question most often missed in my experience.  Our vision is all about the success of the system, but errors occur, and those must be defined as well.  In the ATM example, a user might not have a high enough balance to their account.  The ATM might not have enough cash on hand, or the dispenser automation might be broken.  The list of potential errors can get lengthy, but they need to be examined.  This long list can be simplified into an “exception bucket” that covers errors we can’t think of, but the more we tightly define the errors and corrections the more reliable the result will be.

    Do I need to communicate success or failure of this requirement?

    I see this question skipped more often than I expect.  Once a requirement can be considered a success or failure, does a notification need to occur?  This may be a report, a log entry, or any other communication method.  We might even want to provide multiple responses.  In the ATM example, the notification is likely a printed receipt (report), a beep or sound to note the process is complete, and a message on the screen.  Success is the most likely result to be communicated; it is the error communication that we often forget to define.  Do we ping a maintenance service if the cash on hand is insufficient?  Do we notify authorities if the authentication is a blatant fraud attempt?  These sort of error messages should be defined and are as important (maybe more so) as the communication of success.

     

    Defining requirements is an art form of sorts, but following some simple guidelines can make anyone more effective.  If your requirements have not considered and answered these questions then doing so can improve the likelihood of a successful project.