ANSWER

This question implies that the benefit of foregoing the creation of a more complete requirements specification document is a significant amount of time savings.  But what might we be losing in the process.

Screen mockups alone don’t clearly document requirements.  Instead, they reflect a decision made by the system designer to satisfy a particular requirement.  Often when someone views the mockup or updated system they may think the requirement is obvious when, actually, they have misinterpreted the true requirement.  

For example, imagine that you are updating a business networking site.  The product manager (or systems analyst) makes a freshly altered mockup which shows that the users of the site should provide their full address as part of their profile screen.  What is the requirement here?  Perhaps the rest of the design and development team has assumed that there exists a need for the full address for mailing information to the user.  In reality, this was just the product managers design choice.  The address was needed so that users could search the network by name and if they found multiple people with the same name the city could be used to accurately identify which person they were looking for.

This may seem like a minor example, but as system changes become more routine and complex the problem becomes magnified.  For systems with several distinct user groups there are often competing needs.  So a change to meet one requirement can actually break the system such that it no longer satisfies the requirements of a different user group.  Compromises must be made, but without a detailed understanding of all of the requirements and which users they support an educated decision cannot be reached.  Inevitably, the product manager will begin to forget some of the details of various user requirements over time.  Furthermore, if the product manager leaves the organization this information is lost forever.

Some common challenges that arise from simply updating mockups are:

1. While updating mockups may seem to save some time in the short term, it often leads to a culture of taking shortcuts and not performing the appropriate amount of analysis longer term.
2. Time is wasted over the long term while trying to determine the original requirements and needs, or even reworking changes that were made because a screen was updated for one user group that conflicts with the needs of another user group. 
3. The project team not only needs to remember “What” each group needs, but also understand “Why” they need it in order to manage conflicting requirements between user groups.

Of course, if you are updating a fairly simple system that will have few changes over time then some reasonable shortcuts can be taken.  But how much time are you really saving?  During the initial development of the application you probably spent a considerable amount of time creating initial requirements documentation. The lion’s share of the work is done.  Making small but thorough updates to the requirements documents going forward will require much less time. And in most cases, not properly documenting and managing requirements over the long term proves to be a more costly decision.

--
Chris Adams
LinkedIn Profile