Requirement-Centric Method for Application Development - CiteSeerX

© Copyright EMSISE’03

Requirement-Centric Method for Application Development Smita Ghaisas, Ulka Shrotri and R. Venkatesh Tata Consultancy Services 54 B, Hadapsar Industrial Estate Pune 411 013, INDIA Phone- 91-20-6871058 Email: {smitasg, ulkas, rvenky} @pune.tcs.co.in

Abstract Poor requirement specification is a source of many defects in software application development. To address this problem, we propose a requirement-driven method — MasterCraft Agile Process (MAP). The proposed method separates the problem domain and solution domain clearly and identifies four distinct contexts for capturing, analyzing, modelling and prototyping requirements. It is for the first time that types of requirements have been explored as the basic distinguishing criteria for defining viewpoints. In this paper, we focus on analysis of functional requirement models to detect inconsistencies. We show how modelchecking, simulation and prototyping of functional requirements can help consolidate requirements at an early stage of software development. Once validated, the requirement models can be used to synthesise an implementation using standard design patterns. Some of the proposed techniques are implemented in a casetool — MasterCraft. The separation of functional and technical concerns prescribed in our approach and supported in our tool-set empowers the application developer to adapt efficiently to changing requirements and thus renders agility to application development.

1. Introduction The primary test of the success of software is the extent to which it meets its intended purpose. Requirement capture and analysis are processes that help in discovering that purpose by identifying stakeholders and their expectations, and capturing these expectations in a form that is amenable to analysis and implementation. It is a regular observation that software projects fail to meet their expectations 1 due to problems in articulation of requirements, poor quality of analysis and quite often, a lack of sufficient focus on the business perspective. There is clearly a need to explore approaches that empower application developers in managing requirements better. To address this problem, we propose a requirement-centric method – MasterCraft Agile Process (MAP) – as supported in MasterCraft – a Tata Consultancy Services (TCS) tool for model-driven application development. We separate the problem domain and solution domain clearly and classify requirements into four distinct contexts. We refer to these contexts as viewpoints. Each viewpoint addresses requirements relevant to it and provides a solution that meets those requirements. Transition from requirements to an implementation is automated through the use of tools that incorporate well tested design patterns, guidelines and strategies. A change in a requirement can be confined to the viewpoint that addresses that type of requirement.

1

© Copyright EMSISE’03

2. Related Approaches and Methods The notion of viewpoints is explored earlier. The Rational Unified Process (RUP) 2 prescribes a Use Case-driven approach and defines views for application development. The Reference Model of Open Distributed Processing – RM-ODP 3 also uses the notion of viewpoints for this purpose. In the MasterCraft Agile Process (MAP), we explicitly use the types of requirements as the basic distinguishing criteria for defining viewpoints. The KAOS 4 approach presents a goal-oriented requirement elaboration method. The method goes by the route of identification, structuring, refinement and formalization of goals. KAOS focuses on formal refinement of high-level goals into system constraints meant as functional requirements. Enterprise Knowledge Development (EKD) 5 is a refinement of the Enterprise Modelling to accommodate change management. The focus here is on alternate scenarios for change and selection of the most appropriate one. These are goal-driven approaches and they focus largely on the enterprise modelling part of application developmennt . Our approach focuses on clearly separating and classifying requirements based on their types — i.e., viewpoints and on structuring the solutions around these viewpoints. Tool-assisted transitioning of requirement models to an implemented solution on a deployment platform is an important focus area of MAP. A complete solution is synthesized from the individual solutions by applying design strategies, patterns and guidelines implemented in our tool-set. MAP enables developers to manage change locally within each viewpoint by confining the impact of changes to relevant viewpoints. The agility in our approach comes from a tool-assisted transformation of requirement models into an implementation. We emphasize consistency checks between the same information captured from different sets of users and tool-assisted analysis. MAP ensures quality throughout the development cycle by clearly outlining V&V in each viewpoint and by testing artefacts produced by each viewpoint independently.

2

© Copyright EMSISE’03

3. The requirement-centric Viewpoint model – an overview Fig. 1 shows our viewpoint model schematically. The problem domain addresses business requirements while the solution domain addresses the technical requirements. The requirement models in problem domain capture business objectives, (rules + policies) and processes that implement the objectives as well as enterprise architecture that must support them. These are essentially computation independent in nature. These models contain sufficient detail and precision to enable tool-assisted analysis and simulation. The Functional Requirements Viewpoint (FRV) and the Functional Architecture Viewpoint (FAV) comprise the problem domain. The models in the solution domain address non-functional requirements and leverage state-of-the-art technology to define an implementation platform. The Technical Architecture Viewpoint (TAV) and Deployment Architecture Viewpoint (DAV) comprise the solution domain. The models of the problem domain are automatically transformed into an implementation on the deployment platform by applying design patterns, strategies and guidelines. This approach makes it possible to confine changes in business requirements to problem domain models without having to deal with their platform-specific impact. It also lets a technical developer focus on exploring technical architectural solutions without having to worry about the business functionality. This separation of functional and technical concerns empowers the application developer to adapt to changing requirements efficiently and thus renders agility to application development. Each viewpoint addresses requirements relevant to that viewpoint. Development proceeds along each viewpoint using the standard — requirements capture analysis, specification/coding and testing — cycle. The key point to note is that the artefacts produced by each viewpoint are tested independently of other viewpoints.

3.1

Functional Requirements Viewpoint (FRV)

Functional Requirements Viewpoint addresses application functionality requirements from the business user’s point of view. The business users can be of two types: managers / business process owners who can give inputs on business rules, policies and processes and hands-on users who can give inputs on tasks to be performed using the application, in order to implement the processes. The business processes captured from managers/ process owners are elucidated by identifying process steps. These may be manual or automated. Use Cases captured from hands-on users should be consistent with automatable process steps. Also the business rules captured from managers/ process owners should be consistent with validations specified by hands-on users. Detecting inconsistencies in requirements captured thus from different users can help in consolidating the specification. We use model checkers to automatically detect inconsistencies. Important FRV artefacts include a glossary of business terms, objectives, rules, processes, policies, use cases and validations corresponding to use cases. The artefacts also include business entity models. The prototypes are functional prototypes that would give the users a feel for the realization of desired application functionality.

3.2

Functional Architecture Viewpoint (FAV)

Functional Architecture Viewpoint addresses requirements pertinent to the enterprise architecture. Identifying and defining components to be developed, making decisions about the reuse of existing components, purchase of commercial components and determining the inter-component interactions are important activities in this viewpoint.

3

© Copyright EMSISE’03

3.3

Technical Architecture Viewpoint (TAV)

Technical Architecture Viewpoint addresses non-functional requirements necessary to implement the business requirements defined in the problem domain viewpoints (FRV and FAV). Precise quantification of non-functional requirements such as performance and usability, identification of technical components, mapping of the enterprise architecture components (identified in FAV) onto the technical architecture, implementing the solution and testing it are important activities in this viewpoint. TAV artefacts include multiple prototypes to validate the technical architecture and platform choices compliant with functional requirements. MasterCraft uses platform-independent models (PIMs) of FRV as inputs to generate platform-specific solutions. We thus combine the benefits of the OMG’s Model-Driven Architecture (MDA) and the Agile Development (AD) approach. The MasterCraft tool-set is parameterized by design patterns and well-tested strategies and guidelines that are derived out of a vast consulting experience within Tata Consultancy Services. Separation and classification of requirements has an important consequence. Changes in requirements can be confined to respective viewpoints without impacting other viewpoints. •

If we identify a requirement such as ‘Add copies of a Titl’e in FRV that maintains a One-toMany relationship (One Title has many copies), TAV has a Graphical User Interface (GUI) pattern for a Master-Detail type of screen and a guideline to associate the FRV requirement with this pattern. A GUI corresponding to the FRV requirement is automatically generated. Any changes in requirements pertinent to FRV can be thus specified in FRV without having to change the corresponding GUI.

•

Requirements relevant to TAV such as performance improvements or look-and-feel customizations are confined to and handled in TAV alone without impacting other viewpoints.

•

Strategies for database management Database management strategies include modelling for the table design (modelling tables, columns and keys to the tables along with their mapping to the object model), implementation of the class hierarchies, and class to table mapping. Currently, our tool-set supports one-toone mapping between classes and tables and implements class hierarchy through replication. It provides database management functions and an interface to the RDBMS.

3.4

Deployment Architecture Viewpoint (DAV)

Deployment Architecture Viewpoint addresses requirements relevant to the post-delivery phase to ensure smooth running of a deployed application. Identifying physical architecture, making a roll-out and release plan, installation builds and scripts, training program, user documentation, helpdesk and support mechanism are important activities in this viewpoint. In this paper, we present details of our work on one of the viewpoints viz., the Functional Requirements Viewpoint (FRV).

4. Functional Requirements Viewpoint (FRV) – Capturing, Modelling and analyzing requirements FRV addresses application functionality requirements from the business user’s point of view. Business processes achieve business objectives (through a sequence of process steps) while adhering to a framework of business rules and policies. The diagram in Fig. 2 depicts their associations.

4

© Copyright EMSISE’03

Fig. 2: FRV: Requirement Capture and Analysis

In a typical application development exercise, business processes are captured using text and business entities are captured either using text or the UML 6 class model. Formal specification of rules often gets embedded as validations in code and is seldom captured explicitly. This approach causes the domain knowledge to get locked in platform-specific code and permits re-use only at code level. It prevents automated analysis of requirements, since information about business rules is not available in the form of requirement models. A precise high-level and formal specification of rules would be helpful in automated analysis and simulation of the requirement models. Our tool supports a visual notation to capture these. In this section, we present our work on requirements capture, modeling, analysis and simulation of functional requirements with the help of a case study example. We first outline the actors, activities, artefacts and Verification and Validation (V&V) in this viewpoint. We demonstrate that requirement models can be used as inputs for analysis and detection of inconsistencies. They can be prototyped using tool support. Such an automated analysis and prototyping of functional requirements helps in an efficient detection of rule violations.

4.1

Actors:

Requirement analyst, managers, business process owners, domain experts, hands-on users

5

© Copyright EMSISE’03

4.2 •

Activities Interface effectively with user groups for acquiring functional requirements. o

Functional requirements can be categorized as business requirements (to be captured from managers, business process owners, or sponsors) and user requirements (to be collected from hands-on users). Business requirements address the business objectives at a high level, while user requirements represent the tasks to be performed by hands-on users in order to accomplish those objectives.

o

Identify and prepare a comprehensive list of business objectives, processes, policies, and rules through interview sessions with managers.

•

Use high-level business processes for grouping-related requirements.

•

Elucidate the business processes by identifying process steps. Each process step may be performed manually or may be automated. Associate applicable rules and policies with each process step.

•

Capture user requirements as Use Cases through interview sessions with hands-on users. Use templates to document detailed Use Cases including pre and post conditions, validations. Capture critical scenarios in detail.

•

Illustrate the static structure of an application using business entity model. The business entity model also includes cardinality constraints.

•

Consistency checks in MAP o

Analyzing for consistency between the (same) information captured from different sets of users. ü Check that each automatable process step corresponds to a Use Case and vice versa. An automatable process step such as ‘Issue Book’ in a library system may be conveyed through a Use Case ‘Issue Book’ that includes ‘Check Availabilty’ ‘Check Claim’s and ‘Assign book to Member’ by hands-on users.

o

Analyzing for consistency of invariants ü For each business rule, there need to exist corresponding validations within processes where those rules apply. Also, for every validation, a business rule should exist. A rule such as : ‘An available book shall be held for the claimant, if any’ needs to be enforced by a validation such as ‘Confirm no claims’ before issuing a book to a member. However, if specified informally in a natural language, it is not amenable to analysis. Our tool-set supports a visual notation to specify rules formally and also automates the analysis. Inconsistencies thus detected help in correcting specified rules as well as identifying additional rules. ü Violations of association cardinalities such as ‘A book may be held for at most one claim’ are detected automatically. ü Non-conformance to process such as Return book’ should result in ‘hold book for claimant if any’ is brought out in the automated analysis.

•

Generate rapid functional requirement prototypes to demonstrate core business processes. The focus of this prototype should be to outline the process flow by capturing all the process steps. Automated rapid prototyping is helpful in taking the application closer to user expectations iteratively and efficiently. GUI prototyping is currently supported. Design for a complete functional prototype is in place and we are currently in the process of implementing it.

6

© Copyright EMSISE’03

4.3

Artefacts and (V&V):

Important FRV artefacts include a glossary of business terms, objectives, rules, processes, policies, Use Cases and validations* corresponding to Use Cases. The artefacts also include business entity models that are a result of Use Case analysis. An important V&V step is to ensure consistency between the same information captured from a different sets of users, for example, (i) process steps (automatable) outlined by managers and / or business process owners and Use Cases specified by the hands-on user (ii) business rules specified by managers and / or business process owners and validations described by hands-on users.

4.4

Example

We have chosen a simple library system to demonstrate the results of our requirement-centric approach to application development.

Fig. 3 represents a business entity diagram for the library system. A library maintains a collection of books. Members of a library borrow and return books. On return of a book, if there are pending claims for the title, the book is held for one of the claimants. Table 1 given below captures a simplistic partial enterprise model for such a system. We consider a simple example that illustrates rules that apply to the entity Book in the library system and processes that implement those rules. Table1: Partial Model for the Library System

Business entities Rules

Processes

*

Everything that is a part of the enterprise – persons, things, concepts Policies, Objectives, Laws of land, Domain

Steps to achieve objectives Should not violate the rule

Book, Member, Title, Loan, Claim Rule1: ‘A book shall be issued to only one person’ Rule2: ‘An available book shall be held for claimant, if any’ Borrow Available? -Issue else- put claim and issue when available Return No claims? Make available else – hold for claimant

Business Rule: An invariant directive of an organization Business Policy: A guideline to business while conforming to rules Business Process: A sequence of steps that implement a business rule or policy Use Case: Task corresponding to a process step Validation: A check that must be performed while executing Use Cases so that business rules are not violated

7

© Copyright EMSISE’03

The ‘Borrow’ and the ‘Return’ processes should be checked for their conformance to Rule 1 and Rule 2. We have used UML class models to capture rules, business entity models and activity diagrams to capture business processes. The UML notation is extended using stereotypes 8. Invariant on the entity Book: A book in a library will be either loaned to a member, or held for a claimant or available (if there are no claims) [View Fig. 4]. Borrow: (1). A library member can borrow a book if it is available; i.e., it is not loaned or held for another member. (2) If it is not available, a claim can be put against a title. (3) When available and loaned to the claimant, the claim should automatically get cancelled. (4) A claim cannot be put against a title that is already available and is not held for any claimant [Fig. 5]. The figure does not have specifications corresponding to ‘Put Claim’ and ‘Issue’. The reader is referred to [8] for the same. Return: (1) A library member may return a book issued to her. (2) On return, the book becomes available to other members, if there are no claims against the title. (3) If there is a claim against it, the book should be held for the claimant [Fig. 6]. As in Borrow, the figure does not show the specifications corresponding to ‘Make Available’ and ‘Hold for Claimant’.

8

© Copyright EMSISE’03

After translating the visual specifications into a formal notation, we ran the model checker on the resulting specification. The specification language TLA 7 and its associated model checker TLC were used to verify object models with assertions specifying pre- and post-conditions for operations and invariants. Several errors were detected in the original specification of the library system. By inspecting the error trace generated, we were able to locate the source of the error. Several inconsistencies indicating rule violations could be detected out of the original informal specifications. Fig. 7 depicts the process of automated requirements validation.. Rules + Process steps

Fix errors Translate Formal Specification

Automated Model Check Rules Violation

Fig 7. Requirements validation

The errors detected by the model checker were caught either as instances of invariant violation or absence of necessary invariants in our original specifications.

9

© Copyright EMSISE’03

For a small object model such as this, these are encouraging results. Having thus analysed the requirements, a functional prototype complete with a first-cut UI can be generated and used to acquire an early user feedback. Actual implementation of the functional requirements can be done using the approach prescribed in MAP and MasterCraft’s model-based generative support. Using tool-assisted support for formal specification, analysis and rapid prototyping of requirements, a developer can change requirements when necessary, specify them formally, analyze them and detect inconsistencies in them. Once consolidated, their implementation can be done through automated transformation mechanisms. Multiple prototypes and verification and validation (V&V) mechanisms in each viewpoint are outlined to incorporate user feedback iteratively. In each viewpoint we clearly define artefacts, prescribe rapid prototyping and state V&V to be done by users. We have discussed the Functional Requirement Viewpoint (FRV) in detail here. However, a brief description of requirements addressed in each viewpoint pertinent to the Library System is given below. In FAV, the artefacts include identification components to be developed, purchased and outsourced, assignment of requirements to components and inter-component relationships. The end users will evaluate the functional architecture in terms of functionality offered by each component, their logical coherence, modularity, and their potential for reuse. With the Library System discussed here, we can identify Library Management as one of the functional architecture components. The services like ‘Borrow’, ‘Return’, ‘Cancel’, and ‘Reserve’ should be assigned to this component. The Library System may have to interact with an existing Accounts Management component for processes relevant to budgeting and purchase of new books. The TAV addresses precisely quantified technical requirements such as performance and usability. The Library System under discussion may pose the following kind of requirements in the context of this viewpoint (1) It should be possible for 5000 members to log on concurrently. (3) Response time should be not more than 4 sec. The requirement models of the problem domain can be translated into solutions by using design strategies, and patterns supported in MasterCraft. TAV artefacts include multiple prototypes to validate the technical architecture and platform choices compliant with functional requirements. The DAV caters largely to post-delivery requirements like ensuring availability of an application, roll-out and release plans and achieving user comfort. For example, addressing a requirement of 24/7 availability and remote access prompts a developer to examine the necessity to replicate servers and databases at multiple locations, having an archival strategy with minimum down time. Project planning can be done around baselines in each viewpoint, defined as follows. The FRV baseline should comprise requirements that correspond to some of the core business processes and critical scenarios. Correspondingly, the FAV baseline should include business components necessary for incorporation of the business processes identified in the FRV baseline. The TAV baseline should comprise technical architecture components necessary for implementation of the FRV and FAV baselines. The DAV baseline should include partial physical architecture necessary for deployment of the baselined solution.

5. Case Study We applied this to analyze requirements of an Enterprise Resource Planning (ERP) application to check the scalability of our method. The application is for a Chemical Industry with four different sites in India and that has over 500 products. Fig. 8 shows a partial business entity diagram for the system.

10

© Copyright EMSISE’03

Fig. 8: Partial Entity Diagram for the ERP Application

The size of the application can be deduced from the following data: No of Use Cases No of Components No. of screens

400 50 500

For want of space, we present details pertaining only to a process in FRV. Here, we present the Purchase Process as an example. This has the process steps described below: The activity diagram in Fig. 9 below captures captures this process.

Fig. 9: Purchase Process

1. Raise indent 2. Check the required approval level 3. Route to approver 4. {If approved} Include for consolidating indents

11

© Copyright EMSISE’03

5. PO activities: •

Invite quotes from vendors

•

Compare quotes

•

Select quote with lowest price

•

Send letter of intent to vendor

•

Prepare purchase order

Of the process steps outlined above, the automatable ones were used for consistency checks against Use Cases captured from hands-on users. Business users specified some of the rules that apply to this business process, as follows: 1. An item can be issued only to the department for which it is reserved. 2. The same item cannot appear twice on an indent. 3. ISO and non-ISO items cannot be present in the same indent. 4. Terms and conditions in a purchase order should be picked up from the contract (if any exists) with the vendor. Absence of several invariants (rules) was detected through our analysis. Some of them are: 1. Only indents of type ‘Firm’ have Purchase Orders (PO) associated with them. 2. Items in a PO detail should exist in an indent detail corresponding to the indent header. 3. Items should not be repeated in indent details for an indent. 4. The Sender and Receiver cannot be the same for an indent. Our simulations generated a number of interesting scenarios that could be used for verification and validation with the users. For example: 1. An unauthorized employee attempts raising an indent for a department. 2. An indent detail is associated with more than one indent header. Transformation of the FRV requirements to an implementation was done using the MAP approach outlined above.

12

© Copyright EMSISE’03

6. Summary In this paper, we have demonstrated use of our requirement-centric method for application development. We separate the problem domain and solution domain clearly and classify requirements into four distinct contexts. We refer to these contexts as viewpoints. Each viewpoint addresses requirements relevant to it and provides a solution that meets those requirements. We have shown that requirement models can be used as inputs for analysis and detection of inconsistencies and they can be prototyped using tool support. Such an automated analysis and prototyping of functional requirements helps in an efficient detection of rule violations and validations and consolidation of requirements at an early stage of software development. Once validated, the requirement models can be used for actual implementation of a solution using the MAP approach and MasterCraft’s generative support. The integration of intuitive diagrammatic notations with formal tools has opened up the possibility of early analysis of requirements resulting in early defect detection and correction. It is also possible to generate early prototypes of the system being modelled.

References 1. D. Leffingwell. Calculating the return on investment from more effective requirements management. American Programmer, 10(4),13-16, 1997. 2. Philippe Kruchten, The Rational Unified Process – an Introduction, Addison-Wesley, 1999. 10(4): 13–16, 1997. 3. Kerry Raymond, Reference Model of Open Distributed Processing: Introduction http://magda.elibel.tm.fr/refs/UML/odp.pdf 4. Axel Van Lamsweerde, Goal-Oriented Requirement Engineering: A guided Tour, Proceedings RE’01, 5th IEEE International Symposium on Requirements Engineering, Toronto, August 2001, 249-263. 5. Colette Rolland and Naveen Prakash, From Conceptual Modelling to Requirements Engineering, Annals of Software Engineering, 10, 151-176, 2000 6. G. Booch, J. Rumbaugh and I. Jacobson; The Unified Modeling Language User Guide, AddisonWesley, 1998. 7. L. Lamport, Specifying Systems: The TLA+ Language Tools for Hardware and Software Engineers, Addison-Wesley, 2002. 8. Ulka Shrotri, Purandar Bhaduri and R. Venkatesh, Model Checking Visual Specification of Requirements, International Conference on Software Engineering and Formal Methods, Brisbane, September 2003, IEEE Computer Society Press. To appear

13