Due to the recent popularity of IT Systems, the process to develop IT system are getting more complex. The process used in development of large IT systems or software systems is called SDLC (Software development life cycle).
SDLC has many phases and each phase is important for successful development of the software system. The initial and one of the most important phases in SDLC is RE (Requirement Engineering). RE is the task of capturing, structuring, and accurately representing the user's requirements so that they can be correctly embodied in systems which meet those requirements [1].
There are many challenges and difficulties in performing the RE phase. This project investigates and addresses on of the major issues faced in RE. The major issue faced in RE process which this project addresses is elicitation and modelling of NFRs.
Traditionally functional requirements were of the prime importance and many techniques were developed to elicit and model functional requirements. Due to upcoming of advance software systems in the sector of Banking, Insurance, Medicine, etc NFRs have become more important than they were before.
The challenges faced today are that there are no standard methods to model NFRs. There are many other challenges and difficulties in NFRs like they are hard to measure and difficult to elicit. This project aims to solve this problem by proposing a framework which would be capable of capturing and modelling NFRs of the stake holders of the software system to be developed.
The framework that will be proposed will be independent of any modelling technique and can be implemented along with any modelling techniques used today like use cases, BPM (Business process modelling).
The literature review and background analysis is performed in this report. Finally the research methods and research process of the project is described along with project plan and project objectives.
Introduction
1.1 Overview
Software development is a complex process which involves many phases. The process of developing complex software systems and products is called software development life cycle. SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. SDLC is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps [2].
Five phases of SDLC
RE (Requirements engineering)
Design
Implementation
Testing
Verification and maintenance
There have been many changes to traditional SDLC and many new development methods have been proposed in recent years. Some of them are waterfall model, iterative model, spiral model and agile development model. All the different models have their own methodologies but they all share some common phases out of which RE is one. No matter which SDLC model we use each model starts with RE phase. This provides evidence of the importance of RE in software development. This project involves research related to a specific area in the RE phase which will be discussed in the further part of the chapter.
The project involves research to be conducted related to the first phase of the SDLC. One of the challenging tasks in software development is to understand user needs and system requirements. The requirement gathering and analysis is the first and one of the most important phases of SDLC (Software Development Life Cycle). It is important to know correct and exact requirements of the clients or any software system before the development phase. It is the initial phase of SDLC, if done correctly would avoid many failures that may occur in future.
1.2 Motivation
The main objectives of a successful software product or system is to meet the requirements for what it was intended in the best possible manner. Broadly speaking Requirement Engineering (RE) is the process to achieve the best possible way, so that the software product or system meets its desired or prescribed requirements. RE involves identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation [3].
Most of the times the functional characteristics and behaviour of the system is given more importance and are model carefully ignoring the NFRs (Non-functional Requirements), this may lead to key information being overlooked or deferred. This is particularly important when, from a business perspective, the need to address non-functional characteristics is business critical for certain tasks. This usually includes completion time, security privileges, the availability of a business process, and the regulatory or organization constraints that apply [4].
NFRs are important in all software systems and even more important in business critical systems. For some business performance, security and efficiency may be the most important requirements. For example banking system needs security, performance and efficiency and these are one of the most important requirements of the system. It is therefore important to analyse and model NFRs.
In scenarios where a company or clients want to redesign their current system the main requirements in these cases are non-functional. For example a company wants to redesign their current system in order to improve performance, cut down the cost and to increase the productivity and efficiency.
1.3 Research problem
There are many modelling techniques available which enables us to model the requirements. Some of the modelling techniques are Use Cases, Business Process Modelling (BPM), etc. All such techniques available are very efficient and capable of capturing functional requirements but there are no such standard modelling techniques to model non-functional requirements [4]. Due to this non standard approach to model NFRs have given opportunities to failure. The modelling of NFRs is now heavily dependent on the knowledge and experience of the analyst.
This gives an opportunity to research and work in this area to bring out good solution to the research problem. The main research in this project is to critically analyse NFRs and develop a framework which will be capable to elicit and model NFRs. This framework would give opportunity to develop some tools and techniques which the analysts can use to elicit and model NFRs.
1.4 Research Objectives
The main objectives of this project is twofold, one is to Study current Non-functional requirements elicitation and representation techniques and critical analysis of these techniques. Second is to find a way to model Non-functional requirements.
The main outcome of the project will be a framework which would involve elicitation and modelling techniques for Non-functional requirements in software development. The objectives are further discussed in detail in research methods chapter 3.
1.5 Deliverables of the project
1) A comprehensive survey of current requirements elicitation and representation techniques for functional and Non-functional requirements.
2) A comprehensive research on business process modelling and other modelling techniques for requirement elicitation.
3) A comprehensive research on non-functional requirements elicitation and modelling.
4) Case studies illustrating the elicitation and modelling techniques of non-functional requirements.
5) A new framework design for Non-Functional requirements elicitation and modelling.
1.6 Report structure
Chapter 2 involves detail background research about the relevant topics which comes under the scope of the research objectives. The chapter describes RE and two main phases in RE in detail. The chapter gives a brief overview of the types of requirements and then discuss NFRs, importance and a challenge in NFRs. Chapter 3 involves detail description of project objectives and project plan. Research methodologies adopted for the project are explained in the next section. The latter part of the chapter involves tools used in the project and research process. Finally the report ends with the conclusion
2. Background
This chapter aims to give solid foundation which includes description of all the relevant background required for the project. In order to understand the topic, literature review has been conducted by going over relevant papers, journals, articles, books, conferences and dissertations.
The chapter starts with basic description of RE and the phases involved in RE. This gives the basic idea of requirement engineering. The two most important phases in RE that is requirement elicitation and requirement modelling are then described in detail in section 2.2 and 2.3.These two phases in RE serves the bases of research in this project. Types of requirements in software development are discussed in the next section which includes the NFRs and gives overview of other types of requirements along with NFRs. After discussing briefly about types of requirements, NFRs are then described in detail in the next section. Importance of NFRs and challenges in NFRs are discussed in this section. This literature review provides opportunity to spot the research potential and challenges in the project and set a platform for further investigation and research in the project.
2.1 Requirement Engineering
The main objectives of a successful software product or system are to meet the requirements for what it was intended in the best possible manner. Broadly speaking RE is the process to achieve the best possible way, so that the software product or system meets its desired or prescribed requirements. RE involves identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation [3].
The Requirements Engineering Specialist Group (RESG) of the British Computer Society defines requirements engineering as:
"A key activity in the development of software systems and is concerned with the identification of the goals of stakeholders and their elaboration into precise statements of desired services and behaviour [5]."
Zave defined RE as: "Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families [5]."
A seminar on Requirements Engineering organised by the Institution of Engineering and Technology's Systems Engineering Network determine the essence of RE by answering 6 key questions [5].
Who should be involved?
What do they want?
Where (in what context) could it work?
Why do they want it?
How will we know?
When should we build it?
2.1.1 Importance of Requirement Engineering
Software development projects are often undertaken without proper understanding of the needs or requirements of the client and the problem domain. Developers of the software project end up making early design decisions without considering and undertaking all the constraints on the software product or system to be developed. As a result of this early design decisions unnecessary and incorrect assumptions built of the system which end up into a system which fails to meet the expectation of the stakeholders or users of the system [6].
Mistakes made in RE phase can cost heavily to the system developers. Some studies shows that defects cost 10 to 200 times to correct the software system which is operational then if they were recognised during RE. Other studies have shown that reworking on requirement engineering, design, and code defect may cost 40 to 50 percentages of the total project efforts. This shows that RE if not done correctly will not only cost financial losses but will also cost you with extra recourse use with no outcome. The total budget of the software project due to defects in RE phase can range from 25 to 40 percent [7].
Thus it is important to perform the RE phase of the software project more accurately and special importance should be given to RE phase in order to avoid future failures in software development.
2.1.2 Requirements engineering process (REP)
According to Pressman and Sommerville, RE process is divided into three phases, which are executed in an iterative way: (i) requirements elicitation and analysis, (ii) requirements specification, and (iii) requirements validation [8].
REP.jpg
Figure.1. Requirement Engineering Process [9]
In most of the software projects requirement engineering process begins with a feasibility study which results in feasibility report. If the feasibility report suggests that the product should be developed, then requirement elicitation and analysis begins. [10]
Requirement elicitation and analysis
The elicitation of requirements is the first step in RE process. The main task in requirement elicitation is to gather or collect requirements of the system to be developed. Information gathered during requirements elicitation has to be interpreted, analysed, modelled and validated. One of the most important goals of elicitation is to find out the problem and main aim towards developing the system, and hence identify system boundaries. [3]
Requirements Specification
Requirement specification is a description of the software system to be developed which describes the behaviour of the system. The requirements are captured, expressed and articulated in a software requirements specification
The IEEE (Institute of Electrical and Electronics Engineers) has put down eight criteria for an SRS (Software requirement specification) to be considered acceptable and these are: (1) correctness of the requirements, (2) completeness of the requirements, (3) consistency of the requirements, (4) trace-ability of the requirements, (5) Prioritisation of the requirements, (6) that the requirements be unambiguous, (7) that the requirements be testable, and (8) that the requirements be modifiable [6].
Requirement Validation
Requirement validation is a process to validate the requirements of a software system which is to be developed. This process ensures whether we are building the right system, does our problem accurately capture the real problem, did we gather all the needed requirements of all the stakeholders [11].
2.2 Requirement elicitation techniques
Brainstorming: Brainstorming sessions are used in RE so that the stakeholder brings up new approaches and ways to solve the user problem [12].
Workshops: Workshops facilitates meeting with multiple stakeholders to draw out final requirements, to solve any conflicts in requirements and to document the requirements [12].
Interviewing: Interviews are in-person meetings where the business analyst asks questions to get information from the stakeholder. Interviewing helps business analyst to capture relevant and correct requirements [12].
Surveys: Surveys are used to gather information anonymously from multiple stakeholders [12].
Documentation Review: This is the process of obtaining requirements from written documentation such as manuals. Written documents help in determining some useful system requirements [12].
Prototyping: Prototyping means to partially complete the project and to review it with the stakeholders. This method is used to take feedback from the partially developed project [12].
Focus Groups: Focus groups are usually group interviews where the analyst discuss some issues and try to solve them by asking questions and obtaining information from the stakeholders [12].
Observation: Business analyst observes the users in their work place to draw out some requirements by asking them questions about the daily task and work they perform [12].
2.3 Modelling requirements
Modelling requirement is one of the most important part of the RE process in software development. After gathering all the requirements it is important for the RE team to communicate the requirements to other team members and software developers. Modelling requirements helps to achieve this task. Modelling also helps to describe functionality of the system and process flow of the system.
2.3.1 Importance of Modelling
Modelling can guide elicitation
It can help to figure out what are the important questions to be asked to different stake holders. It can help to find and spot hidden requirements which may be crucial in the software system but may have gone unnoticed [13].
Modelling can provide a measure of progress
It can serve as a means to track the progress of elicitation process. Completeness of model will resemble the completeness of elicitation of requirements [13].
Modelling can help to uncover problems
Modelling helps in spotting inconsistency, conflicting or infeasible requirements. It also helps to spot confusion in terminologies, scope and also disagreement among the stakeholders [13].
Modelling can help us check our understanding
Modelling can help in reasoning the requirements, understanding the flow of business processes. It also helps analyst and other developers to visualise and validate requirements [13].
2.3.2 Modelling techniques
Unified modelling language
Unified Modelling Language (UML) is a general purpose modelling language which consists of different types of diagrams each serves a different purpose. Some of the UML diagrams are Use case diagrams, Class diagrams, Package diagram, Deployment diagram, Sequence diagram and Activity diagram. UML is a standard created by the Object Management Group.
UML includes a set of standard notation which enables analyst to model complex software systems.
Business process modelling
Business process modelling in software engineering involves representation of behavioural and functional aspect of a process of an enterprise or company. Business process is represented using BPM. Business process is a set of related and structured activities which are designed to produce a specific product or service. BPM is performed by business analyst to visualise and validate business processes effectively. BPM uses BPMN (Business process modelling notation) which are a collection of notations used to represent BPM.
2.3.3 Types of Modelling
1) Enterprise modelling
Enterprise modelling and analysis deals with understanding an organisation's structure the business rules that affect its operation; the goals, tasks and responsibilities of its constituent members and the data that it needs, generates and manipulates [3].
2) Data modelling
Data modelling is a method used to analyse data requirements of a software system. A data model is a conceptual representation of the data requirements with associated data definitions. Logical data model is the actual implementation of the conceptual data model. Data modelling defines data elements, data structure and relation between the data elements [3].
3) Behavioural Modelling
Modelling requirements often involves modelling the dynamic or functional behaviour of stakeholders and systems, both existing and required. Behaviour modelling helps to model the functional requirements of the software system or product [3].
4) Domain Modelling
Domain modelling deals with an abstract description of the environment in which the software system will operate. Domain models are essential while building automated tools, because they provide reasoning over the close world model of the system interacting with its environment [3].
5) NFRs Modelling
Non-functional requirements are generally difficult to model in a measurable way making them more difficult to analyse. NFRs are generally constraints and properties of a system and hence are difficult to verify for individual components. The project involves working in this area of modelling NFRs requirements and to propose a successful method to model NFRs.
2.4 Different levels and types of requirements
The below figure is adopted from Karl Wiegers (2004), which shows different levels and types of requirements. These levels and types of requirements give clear description of different types of requirements and their relations with different attributes in different levels. These levels help RE process to better understand the user needs [14].
level.jpg
Figure.2. Different levels and types of requirements [14]
User requirements can be broadly categorised into two types
Functional requirements
Non-functional requirements.
2.4.1 Functional requirements
Wikipedia definition of Functional requirements is, "In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behaviour, and outputs. Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioural requirements describing all the cases where the system uses the functional requirements are captured in use cases [15]."
2.4.2 Non-functional requirements
"Non-functional requirements define the overall qualities or attributes of the resulting system. Non-functional requirements place restrictions on the product being developed, the development process, and specify external constraints that the product must meet [16]"
2.5 Importance of NFRs
NFRs are important in all software systems and even more important in business critical systems.
For some business performance, security and efficiency may be the most important requirements. For example banking system needs security, performance and efficiency and these are one of the most important requirements of the system. It is therefore important to analyse and model NFRs.
In scenarios where a company or clients want to redesign their current system the main requirements in these cases are non-functional. For example a company wants to redesign their current system in order to improve performance, cut down the cost and to increase the productivity and efficiency.
Errors or defects generated due to ignoring or not properly dealing with NFRs are one of the expensive type and most difficult to correct. Recent work shows that requirement engineering should address NFRs early in development of the system while later focus on the other requirements [17].
There have been reports that point the cost of not properly dealing with NFRs which resulted in considerable delay in project development and significant increase in the final cost of the project.
Paramax System Crop experienced a major delay in the deadlines and significant increase in the cost during the development of a real time system [17]. There were many reasons for the delay, but one of the major reasons were that NFRs like performance was neglected during the development of the system which lead to several changes in the architecture, design and code of the project.
London Ambulance Service reported a major problem related to NFRs. London Ambulance System was deactivated immediately just after the deployment of the system because many non-functional requirements were neglected during the development of the system. NFRs such as "reliability, reliability (vehicles location), cost (emphasis on the best price), usability (poor control of information on the screen), and performance (the system did what was supposed to do but he performance was unacceptable) [17]."
2.6 Elicitation Modelling and analysing NFRs
Dealing with non-functional requirements involves activities like elicitation, modelling and analysing. Elicitation of NFRs includes understanding the domain and gathering potential NFRs of the organisation. Generally NFRs are not clear in stakeholder's mind, eliciting them is a challenging task. This activity is one of the major parts the framework that will be proposed in this project. Different techniques will be studied and will be implemented in the framework [17].
Once the NFRs are elicited, they are modelled. Modelling of NFRs allows them to be represented for better visualisation, understanding and communication of the requirements. Modelling helps software engineers and analyst to analyse NFRs. Analysing NFRs helps in finding the measure about how well each NFRs is being satisfied and to detect potential conflicts in NFRs by reasoning [17].
2.7 Types of NFRs
NFRs.jpg
Figure.3. Types of NFRs [16]
Some definitions of NFRs by Rob Kremer Rose Joshua, University of Calgary [18].
Reliability: "The extent to which a program can be expected to perform its intended function with required precision."
Efficiency "The amount of computing resources and code required by a program to perform a function."
Integrity "The extent to which access to software or data by unauthorized persons can be controlled."
Usability: "The effort required to learn, operate, prepare input and interpret output of a program."
Maintainability: "The effort required to test a program to ensure that it performs its intended function."
Flexibility: "The effort required to modify an operational program."
Portability: "The effort required to transfer a program from one hardware and/or software environment to another."
Reusability: "The extent to which a program (or parts thereof) can be reused in other applications."
Interoperability: "The effort required to couple one system with another."
2.8 Challenges in Elicitation and modelling of NFRs
Challenges faced in dealing with NFRs are as follows [19]:
1) Often the ability to satisfy NFRs is outside the control of system development and dependents more on the environmental factors. E.g. the ability to cope up with incoming data depends on the environment.
2) It is difficult to see the relationship between functional and non-functional requirements despite the fact they are generally related to one another.
3) Reasoning NFRs is a challenging and difficult task. This may force designer to over specify the constraints of the system which may disrupts the software engineering goal of abstraction.
4) There are no standard techniques available to test and debug NFRs.
5) NFRs are difficult to model as there is no standard modelling technique available to model NFRs.
6) NFRs are hard to make them measurable and to evaluate the scale to which they meet the requirement. NFRs do not have standard measuring units as their counterpart functional requirements; this makes measuring and evaluating NFRs a difficult task.
2.9 Measuring NFRs
Measuring NFRs is often difficult as compared to functional requirements as NFRs do not have standard units to measure it. But NFRs can be measured with some metrics some of the examples are given in the table below.
Example Metrics [20].
NFRs
Metrics
Speed
transactions/sec ,response time, screen refresh time
Size
Kbytes number of RAM chips
Ease of use
training time number of help frames
Portability
percentage of target-dependent statements number of target systems
Reliability
mean-time-to-failure, probability of unavailability rate of failure, availability
Robustness
Time to restart after failure percentage of events causing failure
Table.1. Metrics for NFRs
Summary
RE is a very important and complex process in SDLC. There are many challenges and difficulties in RE which makes this topic favourite for research and a lot of research takes place on this topic. This project addresses some issues related to RE and its relationship with NFRs. This project then concentrates on NFRs and the challenges involved in it. The main focus of this project then becomes to research more on NFRs and to address some solutions to the problems related to NFRs in best possible manner.
3 Research Methods
This chapter outlines the project objectives at first. Further project plan is described in the next section. Followed by research methodologies used in the project, tools used in this project are described in section [3.2]. The research strategy consisting of three phases analysis, design and evaluation is discussed at the last part of the chapter.
3.1 Project Objectives
1. Identifying the relevance of RE in the software development life cycle.
2. Evaluating and analysing existing requirement elicitation and modelling techniques.
3. Exploring types of requirements and their importance.
4. Exploring techniques to elicit NFRs.
5. Exploring and constructing techniques to model NFRs.
6. Formulating and constructing framework for elicitation and modelling of NFRs.
7. Designing case studies and scenarios to evaluate and illustrate the framework.
Objectives 1, 2 and 3 are being addressed through literature that is mentioned above in the Background. In order to understand the topic, literature review has been conducted by going over relevant papers, journals, articles, books, conferences and dissertations.
Objective 4 and 5 will give opportunity to solve the research problem and develop a new framework for elicitation and modelling of NFRs. To accomplice the objectives 4 and 5 more study and research will be conducted in order to understand NFRs in different domains and business areas.
Objective 6 will be addressed by developing a generic framework elicitation and modelling of NFRs. The final framework would be the outcome of two -three iteration of initial frameworks developed from the outcomes of objective 4 and 5.
Objective 7 will be addressed by designing case studies and scenarios in case studies. These real world case studies would help to evaluate and illustrate the framework in real world scenario.
3.2 Project Plan
Project plan is an essential part of project management. The project plan schedules your tasks and tells us how much time each task is devoted. This provides us with a progress measure and allows us to complete a project in specified timeline. Proper project plan is needed to ensure successful completion of the project [5]. Project plan is an important tool for documentation, taking important decisions and also facilitates communication between stakeholders.
The project is divided into different tasks. The initail tasks related to litrature survey are completed and are represented in the chapter 2; these tasks are related to the background research required for the project. Next task was finding real life case studies which are required to evaluate and illustrate the project findings and to get it approved by the supervisor. Finding real life case studies is completed and is been approved by the supervisor.
Designing case studies task will be done after exam in June alongside the development of the first prototype of the framework. After evaluating and examining the prototype with supervisor second prototype of the framework will be developed in July. The final prototype will be developed in mid July. Evaluation of the framework will be done using case studies in 3rd and 4th week of July. Remaining dissertation writing work will be started alongside evaluation of framework in July and will continue till August last week. Detail list of task and timeline associated with them is given in the appendix A.
3.3 Tools
The projects will use all open sources and free software tools. Modelling tools are required for designing and developing the framework for elicitation and modelling of NFRs. Modelling tools are also required to illustrate and represent the case studies. Business process modelling (BPM) will be used to illustrate the case studies while Unified modelling language (UML) will be used in designing the framework.
Free BPM tools are
TIBCO Business Studio
TIBCO Business Studio is a Free Business Modelling Software with the purpose to unify modelling, management, simulation and implementation of a process within an environment.
Bizagi Process Modeller
Bizagi Process Modeller is one of the easiest to use process modelling software in the BPM Market. The software's drag and drop features makes it very user friendly, even a non technical person is able to create and map out processes.
Questetra BPM Suite
Questetra BPM Suites more than just modelling software it's an entire BPM Suite. The free version of this software allows a maximum of 10 processes to be executed concurrently.
Bonita Open Solution
Bonita Open Solution is an intuitive and powerful open source business process management solution which is applicable for simple to complex processes.
Free UML tools are
Papyrus: Papyrus is tool for modelling with UML2. This is a open source tool which is base on the Eclipse environment.
StarUML: StarUML is an open source software tool which is used for modelling in UML. It runs on Win32 platform.
Open ModelSphere Open ModelSphere is a powerful tool for modelling data and process. It is a platform independent tool which can run on Windows as well as Linux. It is developed and designed in Java.
BOUML: BOUML is a free UML 2 tool box allowing you to specify and generate code in C++, Java, Idl, PHP and Python. BOUML runs under Unix/Linux/Solaris, MacOS X (Power PC and Intel) and Windows.
3.4 Research Methods used for the project
One of the most common research methodologies in computer science is constructive research methodology. Constructive research refers to developing a new artefact that solves a particular domain problem in order to create knowledge which would help to illustrates how it solved the problem. If a solution to a domain problem exists the research method also involves developing artefacts which illustrates how the new solution developed is better than the previous ones [23].The new artefact developed can be practical theoretical or can be both. The new artefact can be a new theory, algorithm, model, software, or a framework [21].
The constructive research methodology will be adopted for this project. This project will use constructive research method to analyse, design and build a framework for elicitation and modelling of NFRs which would provide an integrated solution to the research problem.
Prototyping method will be used in development of the framework for elicitation and modelling of NFRs. A prototype is the initial sample design or model built to test a concept or process which then acts as a medium through which the design progress of the concept can be measured and learned [22].Prototypes are widely used in computer science in designing and expressing many complex computer artefacts [24]. Many complex concept or system designs in computer science are difficult to represent. New designs often have many uncertain and unexpected problems. A prototype allows the engineers and designers to explore and test design alternatives, learn from it and measure the progress of their work until final design gets evolved [22].
Prototyping method will be adopted in developing the framework in this project. The prototyping will serve as a measure to track the progress while designing the framework. The framework will be finalised after two-three iterations. In each iteration a prototype will be developed which will also be used to discuss the design with the supervisor.
3.5 Research process
The research strategy of the project is divided into three phases analysis, design and evaluation.
3.5.1 Analysis
Analysis of RE methods and modelling techniques forms the bases of the project. Analysis in this project includes doing thorough background research on requirement elicitation and modelling techniques. Describing RE and modelling techniques is mentioned in literature review of the project in section 2.1-2.3. NFRs are and techniques are analysed to suggest some very efficient techniques for elicitation of NFRs. Importance of NFRs in different software systems and projects is studied to achieve strong understanding of NFRs.
Analysing the present modelling techniques, issues associated with it and challenges in modelling gave the motivation in realising and understanding the difficulties in elicitation and modelling of NFRs. Analysing developed an opportunity for research in this field to solve the research problem associated with elicitation and modelling of NFRs. Detailed analysis of different modelling techniques and challenges in modelling NFRs will be performed throughout the project lifecycle as modelling requirements is the key for developing a solution to the research problem.
3.5.2 Design
Design phase of the project is the most important phase of the project. Design phase is carried out after the analysis phase. The design phase will include designing framework and designing case studies to evaluate and illustrate the new framework developed.
Framework Design
Prototyping methodology is used in designing the framework.
The framework for elicitation and modelling of NFRs is divided mainly into two parts.
Elicitation of NFRs.
Modelling of NFRs.
At least two techniques will be proposed to derive NFRs.
One of the techniques is Stakeholders concern.
Stakeholders concerns
Stakeholders normally have a number of "concerns". When the users have some requirements which are non-functional they are generally the concerns of the users. Concerns are typically non-functional [16]. E.g. Safety, performance, maintainability, security, etc.
Concerns of stakeholders can be broken down into sub-concerns and then the sub-concerns can be broken down into specific questions. Questions act as a check list to ensure that specific requirements do not conflict with global priorities [16].
Consider an example where the stakeholders concern is safety: The concerns are broken down into sub-concerns and then to relevant questions by which we can derive NFRs.
derive.jpg
Figure.4. Deriving NFRs [16]
Modelling
For modelling NFRs at least two techniques will be proposed. The design will consist of notations which will be proposed after further deep study. The proposed notations will be used along side
Business Process Modelling (BPM) but latter can be implemented with any other modelling technique like use cases.
The first technique is adopted from IBM research paper [4]. The technique involves use of two proposed notations, operating condition and control case, for capturing high-level non-functional requirements during business process modelling. The operating condition is the high-level view of NFRs which is usually associated with some functional process or activity of the process.
modelling.jpg
Figure.5. Operating condition and control case [4]
Example to illustrate the above modelling technique is adopted from IBM research paper: [4] consider an ATM business process as an example to demonstrate the operating condition and control case as a means to model NFRs.
atm.jpg
Figure.6. ATM Business process [4]
Case studies design
Case studies will be used to measure how successfully the developed frame work can be implemented in real life scenario. Case studies would also help to develop the framework as the case studies will give a platform to test the framework. Designing case studies is thus an important part of the project. One of the important parts in designing case studies is to design case studies in a way that will address maximum possible types of NFRs and different scenarios in real life. This is the reason why as many as 6 case studies will be designed.
Background research gave the foundation for identifying and designing the case studies for this project. After doing some background research and analysing the NFRs in depth the case studies are identified and categorised into two types. The categorising of case studies would help in developing as well as illustrating the framework to be developed. Further each case study is divided into scenarios which give a distinct representation of each requirement in a particular scenario. This separation of scenarios in a case study would give more focused situation to elicit and model the NFRs using the framework.
The figure below shows the basic categorisation of case studies that will be used in this project:
Case study
Business process configuration
Critical Systems
Scenario 2
Scenario 1
Scenario 2
Scenario 1
Figure.7. Basic categorisation of case studies
1) Critical Systems: Critical systems are the system for which NFRs are very important and they are very critical for their businesses. E.g. online banking systems, Insurance systems, ATM, etc
2) Business process configuration: Business process configuration are the systems which were already built with functional requirements as the prim intensions but now need to be reconfigured in order to improve business process as per their business objectives.
The case studies which will be designed further are as follows
Type 1: Critical Systems
1) Insurance domain
Examples of scenarios
Scenario 1: Policy generation
Scenario 2: Claim insurance policy
2) ATM
3) Online banking system
Type 2: Business process configuration:
1) Manufacturing process of fan manufacturing company
Examples of scenarios
Scenario 1: Improve stock update process and invoice generation process
Scenario 2: Add more security in transactions in the system.
2) Basic online order delivery process
3) Job application system
3.5.3 Evaluation
Evaluation can be defined as
"Evaluation is the systematic acquisition and assessment of information to provide useful feedback about some object [25]."
Formative and Summative Evaluations
Weston, Mc Alpine, and Bordonaro, (1995), "The purpose of formative evaluation is to validate or ensure that the goals of the instruction are being achieved and to improve the instruction, if necessary, by means of identification and subsequent remediation of problematic aspects [27]."
According to Dawn Sutton, "Formative evaluations include needs assessments, structured conceptualization, implementation evaluation and process evaluation. Summative evaluations involve outcome evaluations, impact evaluations, secondary analysis, cost effectiveness, cost benefit analysis and Meta analysis [26]."
For this project formative evaluations as well as summative evaluation will be performed. Formative evaluation would include assessment, implementation evaluation and process evaluation while summative evaluation would include outcome evaluation and impact evaluation.
Evaluation also helps to judge the progress and success of your work. In this project the evaluation of the proposed framework will be conducted using real life case studies. The case studies will illustrate how well the final framework would work in real life scenario. This also gives an opportunity to explore how effectively the framework can be applied in different cases and situation.
Conclusion
The report gives the detail study of background research done for the project. The main aim of the background report is to provide the literature review and research methodology of the project.
In this report an overview, motivation and research problem is provided which gives a clear idea and aim of the project. RE and phases involved in it is discussed with detail description of two phases in RE that is requirement elicitation and requirement modelling. Further types of requirements is listed and NFRs is described and its conjunction with RE is briefed. Detail discussion on NFRs, importance and challenges involved with NFRs has been presented to give more in depth idea and to provide wide scope for research potential in this area.
In the next section project plan along with Gantt chart is provided with detail plan description. Research methodology used in the project, constructive research methodology and prototyping methodology are described. Research process involved in this project which includes three phases analysis, design and evaluation illustrates the work done till date and future work to be done in the project.
