The very first thing that happens in a project's or system's life is its conception. Behind the scenes, that usually involves the recognition of some unfulfilled need, or something that isn't working the way it should, though other variations might occur as well. As part of that realization, there will frequently be a collection of capabilities that the conceived system will provide, benefits or functionality that will drive the system's development, and determine when that development is complete. At this initial, very high-level overview, there may not be much in the way of detail—we need a better way to manage inventory, maybe for the entire vision, for example—but it's possible that more detail will enter the picture, too.

The concept and the benefits might come from anyone with a stake in the system: business staff who are looking for a better way of doing things, developers who perhaps recognize that an existing system isn't as effective as it could be, or maybe that it's difficult to maintain. System administrators might have concerns about how easily managed an in-place system is and want a newer, better approach taken, or the initial vision might be for something completely new, at least in the context of the business setting—we need a way to keep track of fuel efficiency across our delivery truck fleet, maybe. What about if our customers could order our products online?

Hopefully, if off-the-shelf solutions or products are available that meet parts of these needs, those options will have been investigated in some detail—maybe even to the point where the vision owner would be able to point to some feature set(s) of those products and say, "We want something like this." Having examples of functionality that's close to what's actually wanted can be a significant time-saver during pre-development design and development alike, and it's almost always worth asking if there are examples of what's wanted as the design and development processes move along. If that sort of investigation was undertaken and no options were found that were even close, that, too, has useful information embedded in it—what was missing? What did product X do that wasn't meeting the needs in the concept? If no investigation was undertaken, or if nothing came out of an investigation, it's quite possible that the initial concept would be no more than a sentence or two. That's alright, though, since more detail will be extracted later on as the concept development gets underway.

In more formal processes, other analyses may also take place, looking for things such as the following:

• Specific user needs: What users must be able to do within the system, and probably what they should be able to do. There may also be a collection of nice-to-have features—things that users would like to be able to do, but that are not a functional necessity.
• Specific functional needs: What problems the system needs to solve, or at least mitigate in a significant fashion.
• Risks: Usually business-process-related risks, but those may also serve to guide design and development in later phases.
• Costs: Both in money and resources. Odds are that this information won't yield much use from a development process perspective, but it's not impossible for an occasional significant nugget of information to come out of this either.
• Operational feasibility: Examining how well the conceptual system addresses the needs it's been thought up to address. Like with cost analysis, the odds are good that there won't be much that comes out of this that's directly useful for development purposes, but it might identify operational or design areas where there is doubt about feasibility, and those doubts, in turn, may well shape design and/or implementation by the time the system is in development.

At best, then, given either a formal process, or sufficient attention to detail in an informal one, the initial concept might produce information or documentation about the following:

• Benefits or functionality expected from the system (usually at a high level, at least to start with):
  
  • A collection of specific, high-level functional needs
  • A collection of specific user needs
• Specific features or functionality that were not provided by an off-the-shelf system (thus justifying custom development effort)
• Specific risks to mitigate against
• Specific functional or feasibility concerns to address

All of these have at least some value once development is underway and will hopefully make their way into design or requirements, and from there into development.