This is a paper exploring A Resource & Methodology for Designing Requirements.
Pooja Wandile, Ranjan Kumar
Cygnus Software, Pune, India poojaw@cygnus.stpp.soft.net, ranjan@cygnus.stpp.soft.net
Abstract
Business applications involve requirement gathering from diverse sources. The business users are usually unfamiliar with the techniques and methodologies of requirement engineering. This leads to frequent reinvention of the wheel and is usually not the optimal solution for the problem at hand. On the other hand he requirement engineering methodologies, in an attempt to be generic, are often abstract and difficult to put in practice. In this paper we propose a methodology for gathering requirements and a framework for a shared, community resource that can facilitate designing requirements, and the standardization process in the practice.
1. Introduction
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements… No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later” (Brooks 1987)
Business software remains an expensive proposition for most companies today. The industry has responded by examining the potential for standardization and reuse among other things. In this paper we examine the prevalent approaches briefly and relate the problems encountered in practice. We then present the case of a Requirement Design Resource to facilitate effective design of requirements. Finally, we propose the outline of a methodology that has been effective in our experience of developing business applications. We believe that a wider, community resource may go a considerable way in making software accessible, effective, and less expensive.
2. Prevalent Methods
Information Technology is far too strategic a tool today and its use has been widespread in business. This has been ever increasing and it is defining new approaches to business. Software analysts, designers, and developers are, therefore, called upon to address diverse business requirements.
The prevalent methodologies for designing requirements are, understandably, generic. We look at some of them here.
2.1 Software Engineering
A fairly widespread process of gathering requirements follows the following steps, viz.
Requirements elicitation
Requirements analysis
Requirements negotiation
Requirements documentation
Many techniques have been suggested to assist in different stages, e.g. brainstorming, interviews, workshops, and others.
2.2 The UML Approach
Another well-known process – Rational Unified Process - from Rational Corporation includes the following steps related to business modeling, viz.
· Assess business status
· Describe current business
· Identify business processes
· Refine business process definitions
· Define business process realizations
· Refine roles and responsibilities
· Explore process automation
· Develop a domain model
In this approach the requirements are illustrated using the Unified Modeling Language – UML – diagrams like Use Case Diagrams, Class Diagrams and others.
3. Experiences and Ideas
3.1 Experiences
It would be clear that the representative approaches mentioned above are likely to lead to diverse designs of requirements as the suggested steps are generic and they depend on who designs the requirements and how. Techniques like interviews, brainstorming, workshops may all arrive at different designs.
At the same time insights into effective designs for various needs have also been emerging. It is useful,
therefore, that the prevalent approaches take advantage of these experiences and arrive at standardized designs where possible.
3.2 Problems
Christel and Kang (1992) have presented the different problems encountered during the design of requirement, viz.
Problems of scope
· The boundary of the system is ill defined
· Unnecessary design information may be given
Problems of understanding
Users have incomplete understanding of their needs
Users have poor understanding of computer capabilities and limitations
Analysts have poor knowledge of the problem domain
User and analyst speak different languages
Ease of omitting “obvious” information
Conflicting views of different users
Requirements are often vague and untestable
Problems of volatility
· requirements evolve over time
3.3 Requirement Reuse
Cybulski, J. (1998) has presented a survey of the various requirement reuse approaches and also suggested reuse opportunities in various areas, viz.
Elaboration of Needs and Objectives
· Enterprise Model
Requirements Acquisition
· Information Sources
· Elicitation Skills and Resources
· Document Templates and Standards
· Reuse Across Requirements Documents
· Reuse Within Requirements Documents
· Raw Source Information
· Domain Concepts
· Text Phrases
Requirements Specification and Modelling
· Analytic Techniques
· Analytic Processes
· Analysis By-Products
· Refinement Artifacts
· Adaptation and Integration Processes
· Comments and Annotations
Requirements Model
· Analysis and Specification Patterns
· Generation and Evaluation of Alternatives
· Restricting Problem Domain
· Restricting Solution Domain
· Evaluation and Selection
Requirements Verification and Validation
· Verification Rules
· Validation Trace
4. The Case for a Requirement Design
Resource
Although software is a pervasive tool it is also considered an expensive resource to build, deploy, and maintain. Much of the cost can be traced to the problems related to designing the requirements.
There have been advances and widespread acceptance of various software component technologies over the years. These include, e.g. CORBA, EJB, DCOM and other technologies. Consequently, several component libraries are available for reuse. This has significantly facilitated application development and has reduced the development cycle.
A similar success is not visible in the designing of requirements. There are few standards and the methodologies depend substantially on the specific person involved in design. The patterns used by experienced professionals remain largely unarticulated. The business users, on the other hand, have to participate increasingly in designing these requirements. Thus, the field is developing into collaboration across diverse players. The varied experiences and capabilities across the different players necessitate the need for a collaboration resource.
A scenario like this is better facilitated when experiences of the past, best practices, and designs are made available to the requirement designers. While there has been a substantial development in the design patterns the patterns of requirement have not been articulated as much as the insights accumulated over the years would suggest. For instance, there are several design alternatives regarding design of security in different business applications. However, inexperienced users end up specifying custom requirements that one of the well- known alternatives would have met in the first place. Again, as the audiences for requirement patterns are far more diverse these patterns would preferably require articulation in more diverse concepts, terminologies and notation systems than those articulated by Gamma et al
(1995). It is equally important that a certain degree of interoperability across different notation systems is developed.
Different groups of requirement designers, especially the end-users, are then in a position to assemble their requirements using the requirement patterns articulated in terminologies and notations familiar to them.
Requirements may be classified in terms of the following, viz.
· Generic functional requirements
· Domain-specific functional requirements
· Non-functional requirements
Requirement patterns are useful across all these. Among the generic functional requirements some frequently encountered patterns include, e.g.
· Application Requirements
· Security
· Audit
· Assistance
· Training
· Data and Event Integration
· Business Requirements
· Enterprise Models
· Business Processes
· Business Policies
· Operational Requirements
· Configuration
· Control
· Monitoring
· Troubleshooting Aids
· Environment Requirements
· Access and span of authority
· Presentation, computing, network devices and resources
The domain-specific functional requirements are more complex. However, frameworks have been suggested in various domains to articulate their needs in standard ways. These often include, e.g.
· Business objects
· Business events
· Event-action maps
· Analytics and computation
· Business processes
· Business roles
· Business domain principles and rules
Among the non-functional requirements the patterns often may be classified among, e.g.
· Portability
· Reliability
· Usability
· Maintainability
· Scalability
· Auditability
· Availability
Often assemblies and subassemblies of requirement patterns can be created from constituent requirements of finer granularity. These can be used as templates of application requirements and then elaborated further to include the specific requirements at hand.
It would be necessary to develop pattern notations for articulating and for developing catalogs of requirement design patterns. This standardization would then form the basis of a community resource that can be used to collect and maintain insights as they are discovered.
Finally, it would be important this resource actually facilitates decision-making. That means that relative costs in terms of money, effort, skills, and resources should become clear as different requirement designs are selected.
5. Methodology
We propose that the requirement gathering process should evolve into a systematic process of requirement design.
· Requirements are articulated as far as possible by identifying the key design elements available in the proposed Requirement Design Resource
· Where assembly of requirement patterns can be used as templates they may be selected as the first basis of the requirements
· Where assemblies are not appropriate the specific requirement elements are selected and corresponding patterns are then selected
· The selected alternatives define the context of requirements in terms of, for instance, enterprise entities, resources, business processes, policies and so on
· Subsequently, any specific requirements not covered within the scope
· The requirement context is then refined to include the additional specific requirements
6. In Practice
We have developed in-house resources based on the web on the lines outlined in this paper. Our experience has been that for specific classes of projects we are able to select requirements and match them with corresponding design and implementation elements. Thus, the requirement patterns directly facilitate design and implementation patterns.
We have applied these patterns in banking and finance domains as well as in various e-business development. Our experience has been very positive. Such a resource being available at the community level has significant potential.
7. References
[1] Christel M. G. and Kang K. C. (1992): Issues in
Requirements Elicitation, Technical Report CMU/SEI-
92-TR-12 ESC-TR-92-012.
[2] Brooks, F. (1987): No silver bullet: essence and accidents of software engineering, Computer, Apr., 10-19
[3] Cybulski, J. (1998): "Patterns in Software Requirements Reuse." in AWRE’98. Deakin University, Geelong, p. Submitted.
[4] Rational Corporation, Rational Unified Process, 2000
[5] Gamma, E., R. Helm, R. Johnson, and J. Vlissides
(1995): Design Patterns: Elements of Reusable Object- Oriented Software. Readings, Massachusetts: Addison- Wesley.
