International Journal on Advanced Computer Theory and Engineering (IJACTE)
BASICS FOR EASY CAPTURING AND MODELLING OF REQUIREMENTS ELICITATION, ANALYSIS AND DESIGN IN
SOFTWARE DEVELOPMENT PROCESS
1
Kadupukotla Satish Kumar,
2Konda Sreenu,
3Bathula Prasanna Kumar,
4Chintagunta Ambedkar
1Assistant Professor in Computer Science and Engineering, Sanketika Engineering College, Visakhapatnam
2Assistant Professor in Computer Science and Engineering Department, Sir CRRCoE, Eluru
3Associate Professor & Head in Computer Science and Engineering, Mandava Institute of Engineering and Technology, Jaggayyapet
4Assistant Professor in Computer Science and Engineering Department, SRK Institute of Technology, Enikepadu, Vijayawada First Author Email, [email protected], [email protected], [email protected]
Abstract-Computers are the pervasive technology of our time. As computer become critically tied to human life, it also becomes more important that interactions with them are under control. They are no longer a novelty, but are integrated into the fabric of our world, performing both high and low-level tasks. That is, computers may be used to eliminate heavy, redundant work and more.
Sophisticated machines have been deployed to perform remote surgery or detect subterranean landmines in repopulated civilian areas. The increasing importance of computers in our lives means that it is essential that the design of computer systems incorporates techniques that can ensure reliability, safety and security.
We are proud to announce about computers but there is other side of it. Most of the software projects not up to customer satisfaction. Sometimes Customer is not satisfied in Cost, Product, and delivery. To make Software Project more successful we have to follow some framework or principles. Our paper gives some important tips on “How to capture information from various sources like User, Client and Stakeholders”. By using Electronic Gadgets we can capture information more efficiently. Our paper is not solution for it. But it is advisory to follow out work where we have most success. If initial work carries up to the mark then software project success rate may increase.
Index Terms-Computers, Information, Software Project, Success.
I. INTRODUCTION
A. Software Failure
The economies of ALL developed nations are dependent on software [1]. Software is must in everybody’s life today. We use Software to solve problems [2] in Banking System, Computer System, Embedded Systems, Data Mining, Operating Systems, Bio-informatics, Artificial Intelligence, Space Systems, Aerodynamics and any type of Client requirements. In every aspect Software plays key role. Even though it is playing key role there are some faults in it. Only 60 to 70 percentage of Software Projects successful and not up to the mark. There various models and procedures for making software project success. Among them are
Waterfall model, spiral model and iterative software development model. Waterfall [3] is shown in Fig. 1.
Spiral Model is shown Fig. 2. Iterative Software Development model is shown in Fig. 3.
II. INFORMATION ABOUT PROBLEM
If you take any model there are different phases in developing software [4]. For every model the initial model is very important that is none other then Requirements Phase. This is also called Requirements gathering or requirements collection. If a software developer spends more time here then there will be software project success. We can raise software project success rate to more. Requirements phase starts with High risk to low risk. We have to start requirements phase from high risk onwards shown in Fig. 4.
Fig. 1 Waterfall Model.
Fig. 2 Spiral Model.
Fig. 3 Iterative Software Development Model.
Fig. 4 Risk Factors High.
From requirements we move to analysis and design phase and so on. In Fig. 4 you can see graph the parabolic line which starts from high risk and ends above low risk. Requirements Engineering or Requirements Phase or Requirements Collection similar.
In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering or collection. The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name
requirements gathering. Requirements elicitation is non- trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, voice recording, video recording, workshops, brain storming, use cases, role playing, prototyping and templates for capturing user information.
Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.
Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.
Requirements engineering remains one of the most problematic aspects of software intensive Systems development. That is why we start from high risk. For software project if we start with low risk initially then there will be high risk at end of software project shown in Fig. 5 [5].
Fig. 5 Risk Factors for Low.
At the end of software project never risk factor comes down. If risk factor is down then software project is not up to user requirements. Software project is based on Time and Money factor. One or other way the software project should be delivered to client. Finally, Client has a software project with defects. Requirements phase is that phase which should be concentrated more and it should be started from high risk. Then there will be good success rate among software projects.
According to waterfall model after requirements phase we come across analysis and architecture phases.
Whatever we collect in requirements phase are analyzed. In analysis we try to tell that requirements are correct, consistent, right and according to the system. So compulsory requirement phase should concentrate and grounded.
Problems that indicate the challenges for requirements elicitation:
1. Problems of scope. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
2. Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be
“obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility.
4. Problem based on stakeholders. The problems are from different stakeholders. Client or End User could not know about the problem. But they come to known about problem from stakeholders.
Finally, Client and End User do not know mission and goal of the problem.
Guidelines for Requirements Elicitation Process.
Assess the business and technical feasibility for the proposed system
Identify the people who will help specify requirements and understand their organizational bias
Define the technical environment (e.g., computing architecture,operating system, telecommunications needs) into which the system or product will be placed
Identify "domain constraints" (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built
Define one or more requirements elicitation methods (e.g., interviews, focus groups, team Meetings, Voice Recording, Video shooting)
Solicit participation from many people so that requirements are defined from different points of
view; be sure to identify the rationale for each requirement that is recorded
Identify ambiguous requirements as candidates for prototyping
Create usage scenarios or use cases to help
customers/users better identify key requirements
Sequence of Steps for success rate
Twelve steps which must be performed in sequence:
1. Identify the real problem, opportunity or challenge.
2. Study the problem and understand the cause for computing.
3. Identify the current measure(s) which show that the problem is real.
4. Make prototype of the problem origin, like calculation, information about problem.
5. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it.
6. Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly.
7. Define the business "whats" that must be delivered to meet the goal measure(s).
8. Specify a product design how to satisfy the real business requirements.
9. Back track the problem to reduce ambiguity.
10. Requirements can change at any stage of software development. Ready to accept change.
11. Document the Requirements collected.
12. Take a transition to Analysis and Design phase.
III. ANALYSIS ABOUT THE PROBLEM
How we move to requirements phase?
From requirements we move to analysis and then to design phase. By the template given in below we can reduce the time. Our approach will be from requirements, analysis and design and back to requirements in Fig. 6.
Fig. 6 Triangle for Requirements, Analysis and Design.
SOLUTION FOR PROBLEM
Based on client problem we move to requirements phase. Problem can be a Payroll System, Banking System, Accounting System, Insurance System, Online System, Airport System, Reservation System, and
Embedded System and so on. Example of a simple Office System is shown in Fig. 7.
Fig. 7 Office System.
Based on problem, Client area and number End Users we decide the Software Project. After analysis the basic things about problem, Client area and number End Users we move to the next phase that is Requirements Elicitation phase.
Requirement is a hard work. It is divided into 5 points 1. Finding requirements
2. Writing down requirements 3. Measuring compliance - Verification
- Validation
4. Review Requirements 5. Documenting Requirements
Finding Requirements is a critical task. For capturing requirements we can go for UML design. Where UML diagrams gives clarity about requirements. Based on problem first know the persons who use system. The person who uses system is also called as End user. We can interview End users, Client and stakeholders. In interview process a software professional can use template given in Fig. 8. We maintain each template for each use case. Template is used write down requirements about functional or use case name, input details, output details, processing input and output and employee details who deal with the requirements.
Fig. 8 Template for Capturing Requirements
We got user requirements from the use case diagram.
Use case diagram is one way of collecting information from End user given in fig. 9. Use case is functionality in a system. Scenario is an instance of that use case.
Fig. 9 Sample Use case Diagram.
Office Clerk is End user from Fig. 8 and he is initiating process called invoice. Filling of Fig. 7 is given in Fig.
9. The given template is having 6 Blocks.
1. Employee Number- Who deals with requirement?
2. Requirement Number-Each requirement is tracked with Number.
3. Requirement Name -Invoice.
4. Collection of Input Details from End user.
5. Input Process contains calculations about data.
6. Database requires giving information about Items.
7. Basic things that are required to compute process like system date.
8. Output Details.
Fig. 10 Filled Template.
Fig. 11 Measuring Compliance of collected requirements. Measuring deals with verification and validation. This is also called as metrics. We divide template into six blocks as in Fig. 12.
Fig. 12 Six Blocks for Requirement Capturing.
In the collection process we involve Client, End User and Stakeholders. We identify the requirements and number requirements. We note employee number who is collecting the requirements, requirement name and requirement number in block 1. Another block contains input names with data types and there exhibit behavior like Text box, Label, Message, push button or radio so on. The details are entered in block 2.
Block 3 is related to database. Example invoice number is generated automatically from previous invoice number. Previous invoice number will be stored in database. Same way current dates, Invoice grace date (nearly 15 days from current date) and so on are generated based on database.
Database is block 3.
Block 4 is related to output details which are processed from the block 5. Output details can contain message or a parameter or attribute or exception that is processed from block 5.
Whereas Block 5 is the processing block. We calculate the input details to process output. We note the formulas and things that are related to the inputs. One way is that it is analysis part. Here we find things that are correct, right, consistent and according to the system. By this block we can track the inputs also. We give attribute name details. By giving name of attributes it is easy to calculate and track them when there is a problem with input. By this block we can have requirements and analysis.
Block 6 is related to interface. What things should be displayed, data is intended to whom and what is next.
Block 6 can also have notes about all blocks. Block 6 contains interface details and notes.
After Measuring we handle reviewing or fact find of requirements. On the same template we analysis the requirements. This will consume less time then previous software development models. Finally, documentation of requirements collected.
It is easy to develop prototype for the requirements.
Prototype design is also called as Architecture or Design phase. Interface for invoice is given in Fig. 12.
Fig. 12 Prototype for Invoice.
IV. RESULT
The tenth phase in Fig. 13 occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The tasks and work products for each phase are described in Software Development Life Cycle. SDLC is like a step wise where we can make is success. Our paper reduces the step wise system time. Because we collect requirements, analysis collected things and give architecture of collected things. Our process is similar to other models.
Fig. 13 SDLC.
There is time variation between our model and SDLC.
We are maintaining same time cost for requirements and time cost is reduce for analysis and Design phases in Fig. 14.
V. CONCLUSION
In many of the cases End product of Software Development process is not up to user requirements.
Even though Client is paying lot of Bucks for his project he is not satisfied. This is because of initial process of Software Development is not done properly. That means initial details are not captured properly. Our paper gives some tips for initial capturing of requirements. Requirements play a key role in Software
Fig. 14. Comparison between SDLC and our model.
Development Process. Requirements are also called Problem. Problem should be identified properly. There should be a study on Problem. After analyzing the problem it should be elaborated. Gap for the requirements are filled by collecting information from Client, Users and Stakeholders. In the process of information collection one can use Electronic gadgets like Voice Recorder, Even Video Recording, UML as Design models, Conducting Meetings, Viewing user area, collecting manual documents, use templates.
Review everything available on magnified glass. By following some sequence we can reduce ambiguity in initial stage. There are lots of frameworks for capturing information from various sources. This paper will be
useful to everybody who wants to go for better design in creating Software.
VI. REFERENCES
[1] “Process Models, Process Programs, Programming Support” M. M. Lehman.
[2] “Software Process: a roadmap” Alfon Fuggetta [3] “Iterative and Incremental Developments, a brief
history” Larman C and Basili V R
[4] “Empirical studies of Agile Software Development: A Systematic Review” Tore Dyba, Torgein Dingsoyr
[5] “The Omni Bus Model: A new model of Data Fusion?” Mark Bed Worth and Jane O’Brien [6] “Information Systems Development
Methodologies: A Classification according to problem situation” D. E Avison and V Taylor [7] “Software quality and agile methods” Ming Huo,
Verner J, Limny Zhu and Babar M. A
[8] HSM: A hierarchical spiral model for knowledge management” Z. Sun and G. Hao.
