Java modeling: The proper process of requirements collection work

Software visibility Issues

The difficulty of conceptualizing new software applications varies depending on the project. While the needs of some projects are straightforward--perhaps like applying a new technology to a well-known area--other project requirements may be more complex. As we continue to use software technology in uncharted areas, the behavior of creating requirements for software systems is a conceptual innovation. This innovation is not just an individual's complex mental work, but also the difficulty of communicating with larger development groups.

Frederick Brooks describes the attributes of new software applications that are difficult to conceptualize and describe as software invisibility. Although other areas such as hardware have physical manifestations, there is no software domain. We can see or evaluate the effect of a software application, but its system manifestation is essentially thinking. That's one of the many reasons we create and rely on software models. The model gives the software a physical dimension so that we can better understand and express its direction.

The center of any software modeling effort is demand gathering. The choice to implement the requirements collection process depends on a larger environment for the development project. This environment can be found in the requirements collection process itself, or in another acclaimed model. In some cases, this environment can even be found in the process of deliverable use. By examining where we are exploring the different requirements, we can always identify where the requirements of the system reside. The demand environment is an area of our invisible confrontation with software.

The choice of the proper working process

The implementation of the selected requirements collection process greatly affects the success of the Software development project. Because demand gathering is the basis of the development cycle, an ineffective or poorly chosen requirement analysis process greatly increases the likelihood of project failure. This possibility leads us to cling to known processes, often associated with a separate, favored software development approach.

The requirements gathering process discussed here is abstracted from three best-of-breed software development methodologies: Rational Unified Process (RUP), "functional-driven development" (Feature-driven Development (FDD) ) and "Extreme Programming" (Extreme Programming (XP)). Each method provides a number of excellent tools to assist in the requirements gathering effort. To conform to the sub holistic development approach, we will focus more on the necessary parts-the requirements gathering process associated with each method-rather than the entire method itself. In addition, we will see if we can organize a more dynamic and variable demand gathering process.

The four most common requirements collection processes are the traditional Software collection specification (software requirements Specification,srs), use cases (uses cases), functional features (features), and user stories (users stories). In the next few sections, we will consider each process, paying special attention to the requirements environment--that is, each process provides the right situation to maximize value and the unique dynamics that each process brings to the development project.