Beginning With a Concept

The decision to develop an application on a network is not a simple one. It requires some time and effort to explore purpose and to consider and select valuable options. A concept document is where all ideas related to the Web application can be gathered and organized, worked and enhanced, and held for later scrutiny and analysis.


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













Most software application development efforts begin with one of two notions. The first notion is that there is a productivity or logistics problem that needs to be resolved. That problem is usually based in some issue(s) related to cost or time or both. The second notion may or may not be based in any real or perceived need but nevertheless springs from the often expressed notion: "Wouldn't it be cool if we...?"

Both notions, however they may be expressed, suggest that things could be better and that a clever adaptation of information technology could be the solution.




...or step back. Occasionally this is the smart thing to do.




But the "concept" of an application (or a domain of applications on the Internet) requires more than a brief passing consideration of the possibilities  before deciding to leap .

QUESTIONING THE CONCEPT

Around any concept that must be discussed and vetted, there are key questions related to:

  • purpose (what is this application supposed to accomplish?)
  • core functionality (how does this application accomplish the desired result?)
  • stakeholders (who is affected by its implementation?)
  • impact (how are stakeholders affected by its implementation?)
  • criteria for success (why does this application make a difference?)

One could create a very long and detailed statement with respect to the concept. It seems to me, though, that the example shown below or something similar would serve adequately in many cases to summarize a typical application concept and its discussion.

In this particular case, the proposed application is to be used by independent parties contributing to projects in an public network environment. Some of the users ("producers") propose and own these projects. Other users ("resources") make contributions in materials, skills, and services to complete these projects. Information exchanges occur between producers and resources to consummate contract agreements and to work toward project results.




CONCEPT DOCUMENT

Purpose of the Applications Domain




Provide here a purposeful summary description of the business objectives and process of the enterprise. This is the unique carefully considered description of the domain concept. Purpose is described in a simple statement. This does not mean that the purpose is simple or that functionality and data may not be complex. Rather, it sets a theme and a focus on a desired outcome.




The primary purpose for this set of Internet applications within a single domain is to provide a venue in which  project producers and project owners can communicate text, numeric, and visual information that will lead to and create commercial relationships between themselves and project resources that can make valuable contributions in materials, skills, and services to those project efforts.  




This may not be the finished mission statement of the business. But any effort without a mission statement of some kind is like a train without rails. If the mission statement needs to be changed, then change it. Just make certain that it is handy later whenever it might seem like the direction of domain design and development has been lost.




The domain has the explicit  mission  to publish and promote a broad range of project opportunities, to attract a broad and adequate range of resources to meet those project needs, and to ensure that the major share of demand on each side (producers' demands for resources and resources' demands for project opportunities) is easily and efficiently satisfied on a consistent and continuing basis.

Stakeholders and the Impact of the Applications Domain




The attempt to engage a broad slice of humanity in any user base is common but it is not always desired. It is important to recognize and distinguish between those who will actually use the application, those who will not use but will depend on the information produced by the application (say, management), those who will benefit from the use of the application (say, shareholders), and those who may have an interest but no real stake. Since this is a generic description, I will leave the specifics of the user community to your imagination.




The domain and its applications are intended to become a focal point of interest for [specify the target audience(s) of the user community]. The domain should have the capacity to attract and serve the broadest possible portion of  this user community , regardless of the individual user's influence, accomplishments, portfolio, or resources [or provide the attributes that would best describe the desired audience].

The primary functional roles addressed by the domain's applications are [specify functional titles or summary descriptions of the interests of the primary players and users]. These roles will provide and respond to information about [specified] opportunities, make [specified] decisions based on that information exchange, and consummate [specified] transactions related to these opportunities.

It is anticipated that information found in the domain will be interesting to other ancillary roles within the user community as well as the general public. But these roles will not be permitted to be as engaged in the domain's functionality as the primary functional roles [or otherwise describe who will and will not have access to the applications and how access might be controlled].


Core Functional Requirements




This list should generally describe user actions and system capabilities at a high level. Note that user actions include access and navigation, data entry, data modification, and data retrieval.




The following functional requirements describe in very general terms what minimum application services the domain must provide. Specific business rules are not described here as they are determined by a thorough analysis of user needs and from  a detailed description of the business model .




  • Users on the public side should never need user documentation. The admin side does not have to be so simple.




    It should be assumed that external users have varying technical competencies and, therefore, user interface and functionality on the  public side  of the site domain should be intuitive, simple and direct for all users.
  • The server environment should be designed and developed for scalability to ensure low latency, efficient bandwidth multi-threaded traffic for requests into and responses from the domain.
  • Primary subscribing users ("members") should have secure selective access to certain functions that allow them to conduct their business in a desired degree of privacy.



  • Certain attributes and capabilities are often assigned to roles, e.g., buyers and sellers on an auction site must be separate in the same transaction. Can a producer here also be a resource in the same project? Why not? A deeper analysis may prove this invalid but, at the concept phase, we could consider this a valid possibility.




    Members can have  more than one user role  (defined as [one of multiple named user types]), if qualified and authorized.
  • Members should be able to register and maintain user profile data in a mode that is self-directed and that is easily and efficiently validated by domain administrators for approval.
  • Authorized member access to business applications should require verification of user name and password tokens.
  • The domain should provide a mechanism for payment of member fees using common and conventional payment agents.
  • Member preferences administration should be available from an external "public" user interface (for external users to express preferences) and an internal user interface (for internal administrators to provide support and to obtain usage tracking information).
  • As desired and expressed in the setting of privacy preferences, member presentation of antecedents and experience from profile data should be available to the general member population. As a promotional channel, this may represent a revenue opportunity for the domain.
  • Selected member roles should be able to perform project RFP record data entry (with a preview option) and maintenance with limited modification options.
  • Selected member roles should be able to respond to project RFP record data entry (with a preview option) and maintenance with limited modification options.
  • Selected member roles should be able to respond with interest to proposal submissions and related information, articulate terms of agreement, and consummate agreement transactions.
  • Members should be able to perform project record location with drill-down category selections, browsing, and keyword data entry options.
  • Members should be able to save and recall preferred or commonly used search criteria for their private user account.
  • Members should be able to perform project record attribute comparisons.
  • The domain should be able to enforce, verify, and validate the proper consummation of agreement transactions online.
  • The domain should be able to recognize agreement transactions that have been consummated and assess transaction fees.
  • The domain should provide a mechanism for payment of transaction fees.



  • For example, at the highest level, physical events or global events within the domain that are important to the broad community or, at the lowest level, reminders to a particular member of expected events occurring in a specific personal transaction.




    An events calendar should be maintained on  multiple levels .
  • The domain members' records and related information should provide member-specific on-demand presentation of linked project-related resources found within the local URL and in other domains on the public network. The member at the record level should be able to manage these links.
  • The domain should provide on-demand presentation of linked and referenced text and visual resources of general interest found within the local URL and in other domains. Administrators of the domain should manage these links.



  • A bulletin board type format for open multilateral threaded discussion in managed topic areas




    The domain should provide services for  asynchronous communications . A fully functional discussion environment should be obtained as a component service from a third-party and administered by an internal monitor working over external volunteer monitors assigned to topic areas. Multiple discussion environments should be installed at different locations within the domain to serve different user classes.
  • Real-time chat

    The domain should provide  synchronous communications  in open and private sessions for members only.
  • Not designed for real-time conversations

    The domain should provide  bulletin board services  to announce requests for other assistance or services required by subscribers in their efforts (skills, staffing, materials, creative services, etc.).
  • The domain should provide self-directed tutorials and online support.
  • The domain should provide accommodation for advertising administration.
  • The domain should provide for abuse administration.

Core Criteria for Success




For the purposes of the concept, it is better to have too many of these requirements than too few. The list can always be trimmed with some items to be discarded and others to be planned into later versions of the domain. Retrofitting new requirements later during development is frustrating, expensive, and threatens distraction from the mission.




The  base minimum requirements for successful performance  are that the domain and its applications:

  • enhance existing communications between the members;
  • create new contacts between the members;
  • promote collaboration around individual efforts;
  • enhance opportunities to promote projects from conceptual proposals to finished work;
  • enhance opportunities to locate and compare projects easily and efficiently;
  • enhance opportunities to locate and compare resources easily and efficiently;
  • enhance opportunities to promote and complete worthwhile projects;
  • allow members to make better use of time;
  • reduce everyone's cost of operations;
  • are simple to use at all levels;
  • are easy and efficient to maintain and administer;
  • are financially self-sustaining;
  • are scalable to accommodate a large user community measured in tens of thousands and possible concurrent use measured in thousands;
  • can deliver low latency, efficient bandwidth performance during periods of heavy multi-threaded traffic;
  • are usable on most any type of computer with Internet access (browser standards to be specified later); and
  • can be constructed using common standard software tool and programming technologies.


SETTING SCOPE




The qualities of well planned and well managed projects are defined by (1) the point at which they begin, i.e. extant circumstances, (2) the point at which they end, i.e. the desired result, and (3) the tasks that are included to arrive at the desired result. Tasks that are "beyond scope" are those that are added after the project has begun and that necessarily change the desired result. This usually has some greater or lesser impact on project time and cost budgets.




The discipline of imposing and holding  scope  begins with the discussion of concept. But it is a delicate balance. System concepts that expand in scope to attempt to cure all faults identified in the broader set of enterprise applications can become overwhelmed by the lack of focus on a desired outcome and by the inclusiveness and complexities of unrelated operations and functions. And when scope is too narrow, opportunities to include or merge related business operations and processes may be lost.

Within the scope that is envisioned and that is deemed appropriate, however, it is important to reach for and examine all blue sky opportunities to include in each conceptual discussion of application functionality. It may be difficult to add these things later after application design begins. And after development begins, it may become both very difficult and expensive.

Blue sky notions can be added freely into the conceptual wish list at the beginning. The least practical of these notions will start to shake out of the project as soon as analysis begins. Technical feasibility as well as assessments of time and cost will scale the development effort back to a realistic scope eventually. The hope is that what remains when scope is set and fixed will be the most valuable and useful features to be taken from the concept.

But it is not quite possible to fix scope quite yet. A better understanding of what needs to be included in the application(s) can only occur when the need for the application(s) is better understood. This is done with analysis.



Return to Top.



develop concept, web application, concept document, software development, internet, purpose, functional requirements, success criteria, development project, business model, setting scope, technical feasibility