The present invention relates to capture of requirements of software systems. More particularly, the field relates to automated tools for capturing requirements of enterprise software applications.
Successful design and development of any software system typically begins with the definition of requirements of the system. Requirements may be functional (e.g., what the system does) or non-functional (e.g., how well a system does). Thus, comprehensive and accurate capture of requirements are essential to a successful deign and development of software systems. Software systems related to enterprise entities generally comprise software applications that automate one or more business processes associated with the enterprise. Thus, software systems related to enterprises have the additional challenge of identifying and representing requirements in a manner that is easily understood by both the business users of the software systems, who have extensive knowledge of the business domain for which the system is intended, as well as the application developers, who have the technical knowledge for implementing the software system.
Use cases are one form of capturing software system requirements. Generally, use cases are used to document different scenarios of interactions between a user and a system, conditions for execution and any assumptions. Use cases are typically recorded as narrative text to ensure simplicity and active participation of stakeholders (e.g., end users of the software system being designed). However, in practice, oversimplification and use of natural language in such textual descriptions results in ambiguity leading to a confusing variety of interpretations of the requirements. Thus, requirements have to be continually verified and revisited by the stakeholders, which can lead to untimely calls for changes in the requirements in the later stages of software development. This leads to additional expenditures related to development resources and costs.
Several techniques have been proposed to use formal semantics in describing use cases. While the formal semantics are helpful to the technical system implementation team, they are typically too complex for business and operational users of the system. Some approaches also isolate the capture of functional (e.g., system functionality) from non-functional requirements such as, but not limited to, system metrics related to performance speed, usability and security. Hence, the development team and the business experts participating in requirements definition process do not have the complete view of the system requirements. In effect, they may not have a complete understanding of how the system performs.
Described herein are methods and systems for capturing requirements of a software system. In one aspect, the system is first represented broadly in terms of a business process model comprising one or more activities related to the system. In another aspect, the functional requirements of the system are captured in terms of a task flow model representing workflows between one or more tasks related to one or more activities of the system. In another aspect, the task flow model can be updated to comprise non-functional requirements along with the functional requirements. In yet another aspect, at least some of the non-functional requirements are desirably elicited in the context of the task flow model, which provides an easy to use framework for capturing requirements.
In a further aspect, the capture of the non-functional requirements for at least some of the tasks in a task flow model is desirably based on a classification of the tasks. For tasks classified as user tasks or interactive tasks the non-functional requirements to be captured may comprise usability and performance. In one aspect, specifying usability requirements comprises associating screens with tasks of a task flow model. In another aspect, screens associated with various tasks can be related to each other to form a screen flow. The screen flow can be used to simulate an exemplary usability scenario of the software system being designed. Performance requirements for interactive tasks desirably includes think time for estimating time for user entry of data and response time for system to accept data. In another aspect, requirements for tasks classified as a system task desirably include desired response time for the system to perform the task.
In yet another aspect, security requirements can be applied to task flow models for each activity of the system. Security requirements can be desirably derived from security requirements related to interaction of entities across between different security domains. These interaction based security requirements are synthesized with the system level requirements to derive the overall security requirements for the system.
In one other aspect, captured requirements can be verified to determine their domain context quality by evaluating the degree of use of the appropriate domain terms within the requirements specification, for instance. The foregoing and other objects, features, and advantages of embodiments disclosed herein will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures. The invention includes all novel and non-obvious methods and apparatus elements disclosed herein, alone and in various combinations and sub-combinations with one another and regardless of whether anyone or more of the advantages disclosed herein are satisfied.
Active participation from the business or end users of a proposed software system in its design and development is often very important. More particularly, their participation early on in the development process is often critical for accurately and comprehensively capturing the requirements of the software system. Reducing the complexity involved in capturing the software system requirements accurately and comprehensively leads to an increase in the effective involvement of the end users early in development process.
Unified Modeling language (UML) prescribes use cases as one method of capturing requirements of a software system. Each use case related to a system desirably provides one or more scenarios regarding how the system should interact with a user or another system to achieve a specific business goal. Multiple use cases may be needed to describe the various features of a particular system. One approach to specifying use cases begins with describing business processes belonging to an enterprise and analyzing how the processes should be automated by a the proposed software system. Thus, an exemplary use case specification requires designers to ask business users about what they need from the proposed software system. These needs outline how the users propose to use the system or, in other words, what should the system be capable of doing. These needs can form a basis for use-cases.
One way to reduce complexity in the process of capturing requirements, while also increasing the details of the requirements that are captured, is to adopt workflow notations to document requirements based on use cases and to elicit additional requirements from the end users, including any non-functional requirements within the context of specifying use cases. To achieve this end, it is useful to adopt workflow notations and concepts that end users may be familiar with, that are easy to understand and, that provide for accurate capture of requirements.
Thus, in one model of software development, the software system design begins with identifying business processes of the enterprise for automation by the proposed software system. Business processes are defined as sequences of activities undertaken by users and a system to realize business goals of the enterprise. For instance,
The project is created first at 165 by the marketing team actor 170 within the proposal system 180, for instance. The availability of assets 185 is verified at 186 in the Asset Management System 190. Thus, a set of use cases for the business process model 100 comprising a set of activities performed by users (e.g., Project Manager 160) or other systems (e.g., MAR Proposal System 180) on the lab management system of pharmaceutical testing enterprise may be illustrated in the Unified Modeling Language (UML) notation as shown in
As shown in
After the identification of the activities that are candidates for automation by the software system being designed (e.g., 210-250 in
As noted above, once the various activities (e.g., 210-250) within a business process model (e.g., 100 of
The task flow model 400 depicts the user and system interaction where there is a constant transfer of the control between the user and the system. Thus, each task can be classified as an interactive task involving a user's interaction with the system or a system task involving execution of some functionality by the system. For example, entering a form with user details is a task performed by the user and can be classified as an interactive task. The validation of whether appropriate user details were entered by the user is classified as a system task. Hence, the workflow notation for indicating the task flow is desirably extended to depict the classification of tasks as interactive or system tasks.
Classification of tasks in this manner enables identification of the system and user responsibilities for executing a use case scenario and it provides structure to the end user for defining the requirements of the system. The following Table 1 describes an exemplary notation for classification of tasks as interactive tasks or system tasks.
In practice, the requirements phase of enterprise application development includes understanding the functional and non-functional requirements. For enterprise application, the critical non-functional requirements typically comprise reliability, performance, usability and security. The Software Specification Standard No. 830 promulgated by the Institute of Electronics and Electrical Engineers (IEEE) defines at least some such non-functional requirements. Using the business process models and task flow models to capture non-functional requirements along with the functional requirements allows an end user to discover inefficiencies due to bad user interface design, security issues, and bad performance levels early on in the software life cycle process. Also, based on such early feedback, the requirements can be adjusted by the end users themselves within the context of building a task flow model.
Each task flow (e.g., 520) in turn desirably consists of one of more tasks (e.g., 530) performed in a sequential or parallel manner, which can be indicated by standard workflow notations (e.g., BPMN). Requirements for interactive tasks 550 desirably comprise a task's association to one or more screens 555 through which the user interacts. The requirements for the interactive tasks 550 desirably also comprise screen validation rules 558 which, for instance, are rules that enable validation of input entered by a user. For instance, if a user is asked to enter his or her age as part of an interactive task, one rule may be that the value entered in the age field is verified to be of an integer field. Selected fields in a screen may also be defined in a rule as required fields. The screen related information may be available via a user interface framework being developed for the software system in question.
A task classified as a system task 540 is desirably associated with domain entities (e.g., 545) being created, updated, validated, processed, or otherwise affected by the system task. For instance, a study entity or test entity may be examples of two domain entities related to the laboratory management system 110 in
Business rules specific to a task, but not generally shared by other tasks related to the domain entity, can also be specified. Such business rules (e.g., 548) relevant for processing or validating the task are also desirably specified as a requirement related to the system task. The exemplary hierarchy 500 is used as described below in further detail to provide a framework for defining requirements of a system.
Usability in an application is primarily decided by the ease of information exchange between a user and software system. Requirements related to system usability are desirably captured by associating screens with each interactive task. The usability of a system can be verified by navigating through all the screens associated with the interactive tasks in the task flow. A screen flow is desirably created by associating various screens in terms of relationships that captures how a user might navigate the set of screens. A given task flow can have multiple screen flows depending on the various decisions gateways involved. For example, a login screen could lead to the home page or an error display page depending on the validity of the details entered.
The end users can also desirably specify performance related requirements at the task flow level. Exemplary performance requirements include the expected workload on the various functions of the system and the number of users expected to use the system at any given time. In one example, the workload may be specified in terms of an expected rate of requests of service from a system. Services desirably relate to activities which comprise tasks related to the system (e.g., as in
For each task 705 related to a task flow of a system, whether it happens to be an interactive task 710 or a system task 720, an expected response time or service time is desirably captured. The sum of response times of all the tasks (e.g., 705) in a task flow (e.g., 715) provides the response time of an activity 720 executing a certain set of tasks in a particular one of the task flows (e.g., 715). The expected workload on the system may be specified according to this model as an expected rate at which requests are received for the system to perform a selected activity, such as at 720. For interactive tasks such as 710, a think time requirement 711 is desirably captured. The think time represents an estimate of a minimum amount of time a potential system user spends entering and reading information on a screen associated with the task. The think time may be estimated by an expert in end user behavior.
Once the requirements data including non-functional requirements are specified, an updated task flow model can be generated with the newly added requirements annotating the functional requirements model to more accurately and comprehensively describe the system requirements.
Business rules and the domain concepts are typically important attributes of a usecase. The business rules may range, for example, from user interface validation rules to a complex condition-action rules that affect software system functionality. Ontology is a key mechanism of formalizing domain concepts and is useful in capturing and detailing the domain. Ontology is seen as a technology for managing, sharing, and re-using knowledge of applications in enterprises. Thus, Ontology is a formal mechanism of collecting and using knowledge regarding enterprises that can be re-used in similar contexts. For instance, while designing a software system solution related to a healthcare industry, it is beneficial to have access to domain knowledge developed regarding the health industry. Such knowledge will allow the system to be designed in conformance with various norms, requirements, and rules common to the industry. Providing such formalism using Ontology to capture the knowledge will result in accuracy and re-use. There are a number of different languages that may be used to specify Ontology. They may be broadly classified as frame based languages and web based Ontology specification languages. Frame based languages are more intuitive and easy to use. The Protege Ontology Editor by Stanford University of Palo Alto, Calif. is one such widely used frame based Ontology editor. An Ontology editor enables the capture of detailed domain concepts which are helpful for specifying requirements of a system. For instance, in the exemplary lab management system, the domain concepts that may be defined are for the Study and Test entities. A detailed domain model is defined in the analysis phase where the domain expert elaborates on the domain concepts related to these entities. However, building Ontology during a requirements phase helps in refining the system design and the domain concepts.
The definition of a domain concept desirably comprises the attributes detailing the type, cardinality, constraints, range and allowed values of data types that are processed, entered, and otherwise manipulated by the system. A common Ontology can be shared across the team that is describing requirements so that consistency and conformance can be instituted. Also, the Ontology and related domain concepts often become more refined as more requirements using common concepts are elicited. Detailing the domain concepts including data types and defining their constraints helps the process of identifying exceptions and invalid user inputs of values in screens, for instance.
Security requirements may be classified in the following exemplary manner:
Application level security requirements may be driven by many individual systems comprising a set of applications servicing a particular enterprise. Thus, security requirements of the individual systems may be influenced by not only the general security functional requirements that specify how sessions are managed and user data is protected, for instance, but also the interaction security requirements that specify how interacting parties are identified and authenticated, for instance.
Interaction security requirements are security requirements that are desirably defined in the context of an interaction between any two security entities. Security entities may be classified as belonging to different security domains, while interactions spanning multiple security domains can have various security requirements. Security entities may be personas (users) or systems, for instance. Even the exchange of information between two different applications within an enterprise can have security requirements. For instance, it is possible that different levels of security are required for an application that interacts with all employees of an enterprise, as opposed to applications dealing with human resources that may require higher levels of security. Crossing of a security domain boundary may occur due to interaction between a user and a system, and between two different systems, for instance. A collaboration diagram can be created (e.g., by a Business Analyst) to identify the various interactions across security domain boundaries between various security entities participating in a business process. Each segment then is representative of the interactions between different security entities. The security requirements then can be captured for the relevant interactions.
One exemplary set of interaction based security requirements can be further detailed as follows:
The above requirements can be specified as security requirements for different pairs of segments in the collaboration model. However, an exemplary relationship between two security entities is directional in nature. For instance, the interaction security requirements for a client-server interaction need not be identical when the roles of the security entities are reversed.
Once a business process model of a system is further detailed in terms of a set of activities, the activities can be traced to actors belonging to interaction segments in the collaboration model. Based on the relationship between the participating actors and the respective segments to which they belong to, the security requirements for the use cases at the activity level can be determined and applied.
In addition to security requirements based on interaction related to the software application being designed. There may be general requirements at a system level defined for all applications in an enterprise, for instance. These too are desirably captured and consolidated with interaction security requirements to better ensure there is agreement between security requirements derived at the interaction segment level and the general security requirements at the system level. One exemplary set of general system level security requirements for a system may be listed as follows:
Thus, a security model for an application desirably comprises one or more of the interaction security requirements and the general system level security requirements.
The task flow model 941 updated with requirements can be used in other ways. For instance, the updated requirements may also be used to generate test cases for testing the software system functionality. Also, since usability requirements may comprise screen flows, a simulation of a user's navigation through a set of screens associated with a set of tasks in the task flow can be implemented.
The illustrative software development tool 900 also comprises a domain data interface 920 capable of interacting with a domain expert for capturing domain Ontology related information for updating the domain model 943 in the system design database 940. The domain Ontology information in the domain model 943 can be applied to the requirements specified in the context of the task flow model 941 to verify the quality of the requirements. For instance, the quality of the domain context of the requirements specified in a task flow model 941 can be based on the frequency of occurrence of selected domain terms within the requirements specification.
In one embodiment, the verification of the domain context is implemented by a domain verification engine 950, which also facilitates the entry of data related to domain Ontology via the domain interface 920 to update the domain model 943 stored in the system design database 940. These functionalities can be implemented separately as well. Also, the domain verification engine 950 can be programmed to have the additional capability of providing hints to the user of the tool 900 while he or she is entering requirements data so that appropriate terms and rules are used in the requirements specification to begin with.
Once the quality of the domain context of selected requirements is verified, domain reports 955 are desirably generated. The domain reports 955 can serve as feedback information to the user of the tool so that he or she can make adjustments to the requirements, according to the content of the reports.
A task flow model can be built for specifying the functional requirements of a system. Along with the functional requirements and the flow of tasks, non-functional requirements desirably can also be specified. As noted above this provides a proper framework for capturing a comprehensive set of requirements for the system and most importantly allows an end user to participate in the requirements capture process. At least some of the non-functional requirements can be specified on a task by task basis. As described above, usability and performance are two such examples of non-functional requirements. Thus, software development tool 900 of
The software development tool 900 of
Task flow models 941 in
With reference to
The exemplary PC 2300 further includes a hard disk drive 2314 for reading from and writing to a hard disk (not shown), a magnetic disk drive 2316 for reading from or writing to a removable magnetic disk 2317, and an optical disk drive 2318 for reading from or writing to a removable optical disk 2319 (such as a CD-ROM or other optical media). The hard disk drive 2314, magnetic disk drive 2316, and optical disk drive 2318 are connected to the system bus 2306 by a hard disk drive interface 2320, a magnetic disk drive interface 2322, and an optical drive interface 2324, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for the PC 2300. Other types of computer-readable media which can store data that is accessible by a PC, such as magnetic cassettes, flash memory cards, digital video disks, CDs, DVDs, RAMs, ROMs, and the like, may also be used in the exemplary operating environment.
A number of program modules may be stored on the hard disk 2314, magnetic disk 2317, optical disk 2319, ROM 2308, or RAM 2310, including an operating system 2330, one or more application programs 2332, other program modules 2334, and program data 2336. A user may enter commands and information into the PC 2300 through input devices such as a keyboard 2340 and pointing device 2342 (such as a mouse). Other input devices (not shown) may include a digital camera, microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 2302 through a serial port interface 2344 that is coupled to the system bus 2306, but may be connected by other interfaces such as a parallel port, game port, or universal serial bus (USB). A monitor 2346 or other type of display device is also connected to the system bus 2306 via an interface, such as a video adapter 2348. Other peripheral output devices, such as speakers and printers (not shown), may be included.
The PC 2300 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 2350. The remote computer 2350 may be another PC, a server, a router, a network PC, or a peer device or other common network node, and typically includes many or all of the elements described above relative to the PC 2300, although only a memory storage device 2352 has been illustrated in
When used in a LAN networking environment, the PC 2300 is connected to the LAN 2354 through a network interface 2358. When used in a WAN networking environment, the PC 2300 typically includes a modem 2360 or other means for establishing communications over the WAN 2356, such as the Internet. The modem 2360, which may be internal or external, is connected to the system bus 2306 via the serial port interface 2344. In a networked environment, program modules depicted relative to the personal computer 2300, or portions thereof, may be stored in the remote memory storage device. The network connections shown are exemplary, and other means of establishing a communications link between the computers may be used.
Having described and illustrated the principles of our invention with reference to the illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles. For instance, elements of the illustrated embodiment shown in software may be implemented in hardware and vice-versa. Also, the technologies from any example can be combined with the technologies described in any one or more of the other examples. In view of the many possible embodiments to which the principles of the invention may be applied, it should be recognized that the illustrated embodiments are examples of the invention and should not be taken as a limitation on the scope of the invention. For instance, various components of systems and tools described herein may be combined in function and use. We therefore claim as our invention all subject matter that comes within the scope and spirit of these claims. Alternatives specifically addressed in these sections are merely exemplary and do not constitute all possible alternatives to the embodiments described herein.
Number | Date | Country | Kind |
---|---|---|---|
93/CHE/2005 | Feb 2005 | IN | national |