Building it just like the old system

Many ADF projects are technology replacements, often from older Oracle technologies such as Oracle Forms. In this case, the application to be replaced has typically been developed over many years; the documentation is outdated and sparse or non-existent. As neither the business nor the IT department can articulate what the system does, the requirements tend to become "it should work just like the old system."

From an estimation standpoint, you're on very thin ice here—nobody knows exactly what the system does, but the business still wants to know how long it will take to build an equivalent system. If you are in this situation, try to minimize the project risk by setting up a small project scope (redevelop just a few modules of the system).

From a cost-effectiveness standpoint, you're on equally thin ice—you know it is going to take time and effort to redevelop the modules, but if you build the new system just like the old system, you are providing no benefit to the business. Think about stepping back from the existing screens in order to see what the business processes that the system needs to support are. Often, the business processes have changed a lot since the old system was built, and it would be a shame to miss this opportunity to design an application that really matches what the business needs today. In order to maximize the business benefit from the new system, establish written user requirements as described in the following sections—do not simply write a specification that matches the existing system screen by screen.

Use cases

Often, requirements are specified in the form of use cases. Each use case describes how to perform some task, so your complete specification will consist of multiple use cases. A small system might have less than 10 use cases, while several dozens or even hundreds might be used to specify a large system.

A use case describes the interaction between a person (called an "actor" by convention) and the system. It describes what the system does for the user to provide business value to the actor, thus focusing on what is to be done and not on how it is to be done. It should therefore not contain any technical details about the implementation.

Use cases can be written at different levels of detail, as follows:

If you need a high degree of formality because of regulatory requirements or because the application is being developed by a supplier for a customer, you will need a fully dressed use case. However, if you are an in-house IT department building an application for internal use, you might start out with only brief or casual use cases and flesh out the details as the project progresses.

In the previous chapter, we worked on "Use Case 008 Task Overview and Edit." A more realistic version of the screen for this use case might look like the following screenshot (with a link to a separate screen to edit all of the details):

In a formal description, the preceding use case could look as follows:

User stories

Agile software development methods tend to find fully dressed use cases too heavy and prefer to work with shorter descriptions, usually called user stories. By tradition, these are supposed to be so short that they can be fit on a single 3 x 5 index card. In principle, there is no difference between a casual use case and a user story.

User stories are only useful as requirements if supplemented with some kind of acceptance test description, thus establishing a common understanding between the business user and developer about what constitutes a successful implementation.

Non-functional requirements

In a software development project, it is normal to focus mainly on the functional aspects—what the system should do. However, there are many other aspects to software quality; for example, ISO-9126 defines the following aspects:

It is important that non-functional requirements are documented in a measurable and testable way, just like the functional requirements. Response time requirements need to be specified in seconds (or fractions of seconds) for a specific function:

Performance/capacity requirements need to specify the exact load the system is expected to handle (for example, 50 concurrent users sending a request every second and receiving a response within 0.5 seconds).

One common non-functional requirement is that the system is user-friendly. This is a very inexact requirement and needs to be detailed into something measurable. For example, an untrained user is able to enter five expense report items and submit the expense report in less than three minutes.

Requirement lists

If you are working with formal requirements, you need to collect all of the requirements in a common list where each requirement is given a unique ID. When you are building your test cases to prove that the application works as specified, you can map the test cases to the requirements. If all of the requirements are covered by a test case and all of the test cases succeed, your application is complete.

Ensuring complete test coverage of the requirements for an enterprise application is a major undertaking typically requiring a test management professional.

Screen design

In many enterprise applications, there are a small number of central screens where most of the day-to-day work is being done. Additionally, there might be screens with specific layout and design criteria, for example, graphic dashboard-style screens. If you have produced a use case list, you should be able to identify these special screens easily. You might even have built some of these as part of your Proof of Concept.

If you are redeveloping an existing Oracle Forms application, you can often identify the central screens simply by looking at the size of the FMB files. A typical enterprise application exhibits a few fairly large and complex modules and a "long tail" of smaller and rarely used modules. The following illustration shows the size of all Oracle Forms FMB files ordered by size in an enterprise application:

For these large and commonly used screens, it makes sense to specify the screen layout in some detail as part of the requirements process. With more than 150 ADF components available, it is a good idea to create a component catalog and design all of the screens using components from the catalog only. This provides a more uniform user interface and makes it easier for the development team to build it.

As the UI design is actually a rather small part of the overall development time in an ADF application, and as the UI tends to evolve over the lifetime of the project, it is not cost-efficient to produce a detailed layout for every screen. Typical data maintenance screens will be totally acceptable in the default layout achieved when dropping a data control on to a page as, for example, an ADF Form.

You should design these screen layouts (sometimes known as "wireframes") in a tool that makes it easy to make changes. You can use a specialized tool for wireframe screens such as Balsamiq (http://balsamiq.com), which deliberately produces a handwritten look to make it clear to users that this is just a sketch and can be freely changed until exactly the right design has been achieved. The sketches in Chapter 1, The ADF Proof of Concept, and earlier in this chapter have been produced with the Balsamiq tool.

An alternative is to produce high-fidelity prototypes using a tool like Microsoft Visio—Oracle has made a set of Visio stencils available at http://www.oracle.com/technetwork/indexes/samplecode/jdeveloper-adf-sample-522118.html that you can download and use.

Be careful about using these high-fidelity prototypes (or actual JSF pages) as requirements—you might run into several problems, which are detailed as follows: