Analyzing Use Requirements

A thorough and competent analysis effort can yield major benefits for the subsequent design effort. Analysis begins with close examination of the concepts document to reveal some defined understanding of what the desired application processes really ought to include and the resources that will be required to develop the domain to that outcome.


Building a Web Application

Beginning with a Concept
Analyzing Use Requirements
Designing the Domain
Building the Domain
People and Money

return to the leakyboat

©1997-2014













So, at this point, we have brain-stormed the concept and have created a list of ideas around this concept. The ideas are not proven and not yet fully understood, either in their individual process detail or in how they might be assembled together for the purposes of the domain and its applications.

The step after concept development and before application design is analysis. Analysis provides understanding and validation of the economic feasibility and value of the domain concept and its elements before committing serious effort and money to application design. Analysis begins with the discovery of goals or needs for information, and steps through to verify the processes or "use cases" found within the scope of the application concept that will satisfy those needs.

It also becomes necessary at this time to learn what is at stake in the success or failure of the project and who cares about that. These factors are fairly critical to the success of the coming design phase. In addition to the stakeholders, attention must be directed to the users, taking into account why and how people will be using the application.



EXAMINATION OF PROCESS




A process is a description of change from one state to another.




A primary objective of analysis is to examine, describe, and model business and operations  processes . The recording of a sale transaction describes the transfer of ownership. The recording of a conversation in an online discussion describes an evolving understanding between participants. The successful entry of user name and password changes the recognition of a stranger to that of a friend and thereby triggers access to a different set of user privileges.




It is fairly important for analysts to understand that a scenario is a description of behavior, a flowing process that exists between a beginning state and an ending state. A scenario is not a series of changed states.




The analyst attempts to identify the attributes of starting states, the attributes of desired states, and the  scenarios  that must occur to link the two states. The analyst attempts to identify and describe:

  • who or what role is the primary agent of change;
  • who or what, if other than the primary agent, manages the change;
  • who, if anyone, or what, if anything, contributes to the change;
  • who or what roles are impacted by the change being made;
  • what are the preconditions that must exist to make the change;
  • what event initiates change;
  • what standards are used to deem the change successful;
  • what is the preferred scenario for success (the typical sequential path that satisfies success requirements; steps include (1) a trigger and then (2) an interaction or a validation or change to the system);
  • what are the alternate scenarios for success (successes and failures that branch from the preferred success scenario, described in terms of behavior and response);
  • who or what is notified of the change and what information is provided; and
  • whether change needs to be authorized or simply accepted and recorded.


FOCUS ON THE REAL WORLD

The analysis of change from one state to another is usually apart from the information technology itself and should not be described in a way that might depend on the presence of the technology. The analyst, while fleshing out a concept, should never really attempt to envision business and operations process as implemented in a software application.




Information technology does not make money for anyone except those who sell it and those who service it. For others, it may reduce the cost of doing business or it might make large-scale enterprise operations easier to manage and understand. But for most businesses, IT does not generate revenues.




However, in anticipation of the process being designed into a software application, it is important to describe the special requirements of each process being examined. These requirements are related to performance, information I/O, reliability, and other usability design factors.

There are other important reasons to make  the distinction between the application and the actual commercial events . Analysis is not about how an application should work but, rather, what should it accomplish. The focus, therefore, is in the events and processes that the application is intended to model and record.




The effects of the user on any process and its descriptive information are fairly simple: information can be added, changed, extended, removed, found, and revealed.




Software applications ought to be designed and built to reflect decision-making processes that are actually based on valuable and critical information and proven real-world knowledge and experience. The technology merely guides the user or communicates and  records the events  of the process.




The primary disadvantage of buying application software off the shelf is that businesses will often find that they have to conform their business operations to the software they purchase. In fact, it is far healthier for a business over the long term to focus on its commerce and have systems conform to operations.




If an application is used in response to the interaction with a market, it is useful to analyze the market dynamic and the information the market offers to and requires from its successful participants. A competent understanding of the market allows one to construct the business model that will interact most effectively with the market. The analyst's attention should be on information exchanges and their role in driving user impressions, motivations, behaviors, and decisions.  The dynamics of these exchanges set the foundations for business rules and internal controls. 



PERFECT SOFTWARE IN AN IMPERFECT WORLD

Process can stray from its intended or conventional path. The analyst must consider the normally expected circumstances and conditions that would threaten the successful and optimal completion of a change. These are often due to information availability failures.

A common example of this is whether a user should have to provide an email address in order to sign up for an online service. In most cases, the failure to provide an address will result in a failure to become a member. Unless there is a good reason for failure, though, a good and valuable process should not have to fail merely because a user is unable to provide a standard bit of data.

To avoid this design shortfall, the analyst must be able to describe how exceptions in the real operational environment may be handled. A process often depends on a sequential assembly of information into a complete package that permits a decision to be made with reasonable confidence. There must be some minimum requirement of information for allowing a change to occur. There must be an understanding of alternative information requirements, as well, for whenever standard requirements cannot be met. In the example mentioned above, the analyst might want to consider whether an email address is necessary or whether alternative contact options might suffice.

They are rarely any of these things.




It is not generally believed that an analyst ought to attempt to inventory the minimum knowledge and skills that the primary change agent (or user) must possess to function in a competent fashion. This is commonly done at the end of development when preparing for user training. There is good reason to believe, though, that analysis omitting these considerations leads to the creation of business rules that, in turn, influence application designers to reduce user discretion and options that might otherwise rely heavily on expertise. In other words, systems designed in this way shift the exercise of competence and judgment from the user/operator to the software application. As a result, when attempting to assess the training gap later, it is generally found that less-qualified primary change agents will suffice. In other words, the users of the system get "dumbed down".




It should never be assumed that business and operational work environments are  uniform, complete, correct, or properly controlled . A few organizations are designed. Most organizations have evolved. Most are staffed and organized in reaction to their circumstances and relationships. Most organizations seek or develop workers with  competencies (knowledge and skills)  that yield a consistent and predictable incidence of daily high level decision-making. Others seek or train workers with minimum or narrowly-focused knowledge and have expectations for very basic cognitive and motor skills. Turnover of staff over time can significantly alter the most fundamental notions of role and responsibility and mission as well as the competencies of both the group and its individuals.



LOOKING BEYOND THE OBVIOUS

The analyst should be able to cast a critical eye on what processes should exist and how they should exist as well as examining and describing what, in fact, does exist. Particular attention should be given to processes that do not seem to contribute value to the organizational result. Deconstructing organizational output (product, transactions, results, reports, etc.) allows the analyst to understand the organizational input requirements and the necessary related processes. Comparing the gaps between that understanding and the observations of the actual operational environment provides clues with respect to what processes and controls are missing and needed or may be redundant.

A thorough and competent analysis effort can yield major benefits for the design effort. Analysis begins to reveal some defined understanding of what the desired application(s) ought to be and the resources that will be required to develop the application(s) to that outcome.

The analyst's work should be able to suggest to the designer the optimal operational structures and functions for meeting user goals. Sequential processes should be identifiable from described work flow descriptions. From this information, the designer should be able to design efficient forms and data entry processes as well as formats for reading and evaluating the same information reported from the system for various other users with different interests.

With a better understanding now of the processes that will be required and how they work, we can move forward to the design of the domain.



Return to Top.



needs analysis, goals discovery, scope, business process, change agent, analyst, application requirements, web application, software development, information technology, internet, functional requirements, business model