requirements elicitation frame-work for quality enhancement of critical ...

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

REQUIREMENTS ELICITATION FRAME-WORK FOR QUALITY ENHANCEMENT OF CRITICAL SYSTEMS : A CASE STUDY Hoda Ahmed Galal Elsayed1and Liyakathunsia Syed2 1

2

Research Scholar, Department of Software Engineering, Prince Sultan University, Riyadh, KSA.

Assistant Professions, College of Computer & Information Sciences, Prince Sultan University, Riyadh, KSA

ABSTRACT Human safety in the Middle East is a crucial aspect especially when working on critical mission systems. Any trivial error may result in inevitable dangerous causalities that lead to loss of innocent souls. The main objective of this paper is to introduce a complete study of a system that automates the currently adopted manual process of having dedicated men to control the barriers at the railway crossings when trains pass, the main objective is to reduce the possible human errors resulting from manual control. This study aims to provide a robust solution that adheres to a formal, systematic and new procedure to enhance the overall quality of requirements gathered for critical systems. In addition, it reflects how effective is the usage of goal oriented modelling in requirements elicitation stage for critical systems to define a clear scope and validate requirements against any missing, inconsistent or vague requirements at early stage.

KEYWORDS Automated,Requirements Elicitation, Goal oriented Modelling, KAOS, Critical Safety System

1. INTRODUCTION A railway level crossing is a point of intersecting a bidirectional road and a railway where many trains can cross this point at the same time. At the same time, many vehicles, trucks and pedestrians may need to cross the road, in order to reach their destination, without paying attention to the coming trains approaching the crossing level with a high speed leading to huge number of accidents that claim the lives of millions of innocent people and cause serious injuries every year in the Middle East. Whether accidents are caused by the barrier men’s negligence, undesirable weather conditions or inadequate traffic planning, the need to have a quick solution becomes essential to control the current amount of loss. The main objective of this research is to introduce a system that automates the current process that depends on humans in controlling the barriers at the level crossings. The proposed automated solution is generic and can be easily customized and applied to any country that is suffering from this problem but on the other hand, it requires a lot of in-site equipments (hardware components) and resources that may change the whole structure of the current railway. DOI : 10.5121/ijsea.2016.7102

13

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

The proposed automated system helps in avoiding human error that may result from the manual control. Its implementation is considered a critical mission project that needs a clear set of data from all involved stakeholders in order to provide a better control of this problem. This paper describes the main activities in the requirements engineering process which is concerned with elicitation, analysis and negotiating of the requirements for the system. This paper also reflect the importance of using high level design models and goal oriented modeling’s modern techniques in validating the requirements against any incompleteness or inconsistencies early to reduce the risk of frequently changing the requirements. The organization of the paper is as follows,Section 2 is a literature review that contains some related work that served as a reference for this study. InSection 3, we summarize the proposed methodology used to collect data necessary for this research. Section 4, presents the verification and validation process used to evaluate and manage the accuracy of the requirements and its overall results. Section 5, presents the conclusion.

2. RELATED WORK Poor requirements wererecurrently recognized to be the major cause of system failures thus a great amount of work has been reported recently in the literature that focuses on requirements engineering in general and requirements elicitation and analysis in particularbut we could find only a few proposed modern methods to enhance the elicited requirements and match the business needs of large companies that are investing in the area of developing critical systems that should be built with high quality standards to perform their job efficiently. Moreover, very few analysis methods were proposed to address the non-functional requirements. Most of the work in this area discussed traditional ways of eliciting data but few novel approaches were discovered to solve the problems faced in the traditional ones. Ruhe et al. have presented an approach for use in requirements negotiation called ‘‘Quantitative inWin’’ [18][19], which adds numerical assessments to Boehm’s original WinWin work. Marchant et al. describe an investigation into howa metric can be applied to requirements gathering to determine the likely success of re-engineering legacy systems [17][19]. The proposed confidence metric was used in two industrial case studies to analyse the probable success of the projects.The metric is for use during the re-engineering of Legacy systems. Another empirical study by Knauss et al., focuses on assessing the software requirements specifications quality [16] [19]. They analysed 40 projects developed by undergraduate software engineering students using a quality model for software requirements.Their results suggest that there is a relationship between the quality of the requirements engineering undertaken and project success. In a study by Merugu & Akepogu [12], they proposed a four layered analysis approach for identification of non-functional requirements with some rules. The identified non-functional requirements are validated using a check list and in addition the completeness of the identified non-functional requirements is computed using a metric. Few of the recent studies shed the light on the modern techniques that are used recently to elicit requirements like goal oriented modelling discussed by Axel van [20].Another study done by Kenneth, Anthony Finkelstein and Rachel [19] suggested a new, practical and pragmatic method for managers and analyst to use. This method consists of four confidence factors and a goal oriented framework with a simple ordinal scale to develop a method for assessing confidence in real systems development project. As a result of their study, they showed how assessing confidence in the requirements could have revealed problems in this project earlier and so saved 14

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

both time and money.The main focus of our proposed researchis to unveil how different techniques can be used to ensure the accuracy of elicited requirements in addition to formal validation methods that participate in improving the overall quality of such critical system.

3. METHODOLOGY This project mayinclude many stakeholders where each of them will have specific interests with the system to be implemented and in order to satisfy all their needs, team members should conduct continuous meetings with them as well as conducting face to face individual interviews should be the basic process of gathering the requirements especially when dealing with critical mission systems. The requirement elicitation framework consists of four main activities which will be discussed throughout this paper in details for critical systems. The proposed requirement framework is shown in figure 1, which includes: 1. Elicitation
where different techniques are used to obtain requirements from stakeholders and other sources and to refine the requirements in greater detail. 2. Analysis and Design
where scope and objectives are identified to increase the knowledge of the domain problem. 3. Negotiation
where requirement engineers resolve conflicts, clarify the vague requirements, prioritize requirements and identify the possible risks. 4. Verification & Validation
where defects are detected to guarantee that the predefined quality criteria are met and ensure that the requirements are complete and consistent to reflect the actual customer needs.

Figure 1: Requirement Elicitation Framework 15

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

The requirements elicitation process for critical systems can be classified into 5 main categories[21]: 1. Functional requirements
user requirements of how the system should behave –modeled using use case diagrams. 2. Non-functional requirements
measures the efficiency level of the system. 3. Data
gathered for more accurate results. 4. Implementation / design constraints
programming language, operating systems, delivery date …etc. 5. Goals
defined to guide the team while implementing of the requirements. Before requirements elicitation stage, it’s important for the team to define the main stakeholders to refer to if any assistance is needed. Once they are known, the team should find a way to gather and prioritize their requirements through conducting interviews with them: Appendix A During the interview, team shouldn’t only listen to the stakeholders but they should also contribute to the conversation by asking questions to help clarifying the vague or unclear requirements. Also, requirement engineers should discuss small details instead of just assuming them to avoid any misunderstanding as it makes the process of approving the software Requirement Specification (SRS) easier and it ensures that all aspects are covered in the critical system. After the interview, the Requirement Engineering (RE) team will be able to create the SRS document based on realistic requirements not just assumptions. In the railways system implementation, the main stakeholders areshown in table 1

Possible Stakeholders

Expectations

Ministry of transportation

Replace the current manual system of railways by a reliable automatic system that is safe and secured. Use the system to control the barriers automatically based on the entire view of the crossing level environment and take actions in case of emergencies. Use system to check that everything is working fine as they approach the crossing level Some employees will be replaced by the system Provide the hardware tools needed like cameras, barriers, traffic lights, alarm devices, touch screens …etc. Provide the budget in order for the project to complete in specific time frame. They are indirectly affected by the system that is to be implemented as it makes them safer while traveling or during crossing the crossing level road. They will develop the system that all other end users need and they need to maintain it in case of any emergency. They need to make sure that the railway line is providing

Direct end users – Railway’s onSite Supervisors / managers / emergency team [22] Train Driver Station employees Suppliers Sponsors Indirect customers – passengers / pedestrians / vehicles / general property owners Development team – managers / developers / testers / maintainers. Passenger train operating

16

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

companies / freight operators Railway regulators – who act on behalf of the government

more safety to protect their reputation and increase their customers. They are part of any major decision and any action, plan change needed should be approved by them first to complete the project.

Table 1: Stakeholders list for railway project

An interview similar to Appendix A should be conducted to elicit the main functional and nonfunctional requirements listed below:

3.1.Functional Requirements • • • •

• • •

• • • •

• •

•

The system should be accessible via network by different users like train drivers and station (on-site) supervisors. The system doesn’t require login and password but rather it should be accessible only through fingerprints. The system requires the following components to work simultaneously in a consistent manner: (radars, camera, sensors, barriers, traffic lights and alarm devices) [22]. Cameras should be fixed at the barriers in both directions (left and right) to capture the environmental circumstances and manual actions should be taken in case of bad weather condition (rainy/ sand storms / tornados). Radars should capture the speed of trains that would arrive the station and send a signal if the speed became less to indicate that the train is approaching. Sensors should be scattered along the crossway for a distance 20 km from the barrier on the left and right side and it should communicate with the sensors fixed on the trains. The system should indicate the sensors’ health in RGB format as follows: (1) if it’s not working properly, it should be shown as a red sign on the system, (2) if it’s working fine but not perfectly, it should be shown as blue sign on the system, (3) if it’s working perfectly, it should be shown as a green sign on the system. The system should force the control of the barrier movement up and down in case any problem happened to the sensors or barriers motors. Alarm devices should be provided on the crossing level for people facing difficulty with vision as a replacement to the traffic light feature for others. The system should show a map of sensors to both train drivers and on-site supervisors. In case a train driver noticed that the system shows certain sensor as a red sign, he may notify the on-site supervisors to take quick action and fix it before the train approach the crossing level. The system should notify the train driver to slow down speed 10 minutes before it arrives to the crossing level. The system should allow both train drivers and on-site supervisors to have access to the weather cast and it should notify both if any risk is expected at the crossing level with some emergency tips to avoid possible accidents. The system should allow on-site supervisors to have access to the trains’ schedule that shows source city, destination city, time at which the train should arrive to the crossing level. 17

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

• The system may allow the trains map view to see all possible trips of trains tracked by GPS facility. • The system must allow on-site supervisors to notify trains drivers with any textual message (a red error message will pop up with a high volume alert) or voice mail in case they need them to take an urgent action for safety reasons. • The system should allow train drivers to communicate with on-site supervisors if they need an emergency help via voice mails. • Maintainers and station’s workers should receive any notification from the on-site supervisors through the system to fix any problem with the hardware components before the train arrives. • If the distance, measured by the sensors, between the train and the barrier is > 100 m, the traffic light should be green and the barrier should be open. • If the distance, measured by the sensors, between the train and the barrier is 40 m, the traffic light should be yellow and the barrier should be open. • If the distance, measured by the sensors, between the train and the barrier is 25 m, the traffic light should be red and the barrier should be close. Once Functional requirements are defined, a use case diagram can be built as a high level designto define the main actions the system should provide as shown in figure 2.

Figure 2: Use case diagram for railway system

18

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

3.2. Non-Functional requirements 3.2.1. Safety, security and privacy requirements • • • • • • • • • •

The system should be running on a Linux operating system since it is more secured [22]. The system should be accessed by fingerprints. Design the system to be bug-free and test it accurately for 6 weeks to eliminate the crash risk and ensure at least 99.9% degree of safety [22]. The system shall react to accidents or action failures by sending an alarm to the supervisor. In case of emergencies (for ex. sensors stopped receiving or sending signals), cameras will be used by the system users to manually control the barriers [22]. The system isnot provided as an open source and thus no third party access to it should be allowed. High level of encryption should be used and database that includes trains’ schedule details must be in a locked mode when not in use. All the queries executed should be first tested and results should be verified. The system database should be secured against cross site scripting and SQL injection, should be verified by testing. Sensors health is measured by the system in RGB format to ensure safety and they will be checked monthly for effectiveness.

3.2.2. Backups •

• •

Save backups of the entire code files and database everyday with the timestamp so previous versions of the code can be accessible whenever the current code got unstable or if weird behavior was discovered that led to sudden and unexpected downtimes. Datacenter should be located outside the country to avoid data damage due to any natural catastrophic circumstances and it should be protected against fire accidents. Any change should be approved first by top project managers and involved stakeholders before integrating it to the master copy of the system.

3.2.3. Performance requirements • • • • • • •

The system should support the access of the following categories of users simultaneously: online supervisors, trains drivers. 95% of system transaction (sending signal from sensor to the barrier, traffic light and alarm controlling device) shall be processed in exactly or less than 1/2 second [22]. The system should perform 3 actions (Barrier and Traffic Light, alarm control) in at most 2 seconds [22]. The system must have 0 errors. The system should be operating and available 24 hours per day [22]. The system should run up to 100 processes using (5–10) GB Memory. The system should be able to handle 100s of requests or transactions simultaneously each day. 19

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

• •

The response time of showing the trains map or trains’ schedule shouldn’t exceed 0.2 seconds. Servers’ storage space should be at least 64 GB to allow for multiple version backups annually.

3.2.4. Usability and User Interfaces • The system interface should be user friendly in terms of quickly finding the most required features that users need to perform on the system. • The system should be easy to use for novice users, as it should not take more than 2 hours for users to learn and use. • All images should be of a high resolution without blurry. Most preferably in .jpg format. • Navigation bar along with back and next arrows should be provided in all webpages to guarantee easier navigation from everywhere in the system. • Font to be used should be “Time New Romans” and size of “14” for menus and 12 for inline text. • The station workers and train drivers will be trained on how to use the system. • A user manual will be given to the user so he can refer to it whenever it is needed [22]. 3.2.5. Reliability • • • •

The system should be available for student access via network or in offline mode for 24 hours. The system’s rate of downtimes should be less than 1hour per year and it should be for maintenance purposes. Number of bugs allowed for the whole system should be 0. System’s failure occurrence rate should be minimized to at most once per year.

3.2.6. Portability • • •

The system should be compatible with all operating systems including Windows, Mac, Unix, and Linux. The system should be responsive to the screen size that is opened through. For ex. Laptop or mobile. The system should run on any type of browsers including Internet Explorer, Google Chrome, Spark Baidu, Firefox and Opera.

3.3. Data The following are the main information that can highly affect the accuracy of the requirements being collected for such critical system [22]:    

Schedule of trains passing by the railway Time needed to open/close the barriers. The distance at which sensors should be applied. Time needed by a train to cross the road. 20

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

    

Speed of the trains. Number of sensors needed and their cost Sensors positions (left, right or both). The need of integrating cameras into the system. The need of adding traffic lights/sound systems that would prevent cars and pede pedestrians from passing the railway when the barrier is closing.

3.4. Implementation entation and design constraints • • • • •

The system process should adhere to “Agile” model. The system should be developed using java. It should be delivered by the December, 2017. The system should be developed using visual studio professional 2013. The data should be saved in MySQL database management system.

3.5. Goals It’s important to define the main system goals to avoid scope creeping and to discover the missing requirements or inconsistent ones. One way to define goals effectively is to use the goal oriented models’ modern technique known as KAOS, knowledge acquisition acquisit [7] in automated specification. This model stresses the important goals that the system is implemented to achieve

Figure 3: Goal oriented (KAOS) model for railway system

and helps identifying any missing requirements because of its easy flow of asking how and why this feature is implemented. Providing answers answers to these 2 questions will definitely increase the 21

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

overall understanding of the system. An example on how to apply KAOS model on critical projects like railway system is shown in figure 3. In figure 3, the main behavioral goal is avoiding all sort of accidents that may happen at the level crossing. This goal will be achieved if its two soft goals are achieved, causing no train collisions with vehicles and pedestrians. Moving down the model will answer “how” while moving up will answer “why”. Agents are also represented in terms of humans, device or system component. Conflicting goals can also be represented similar to moving barriers “up” and “down”. This model uses“and / or decomposition”technique to connect super-goals to their sub-goals.

4. RESULTS After analyzing the stakeholders’ requirements, an initial prototype was built for validation purposes. The process of verifying the correctness of SRS can be done informally in many systems, however, in critical systems, a formal review process known as inspection is the best way to validate the requirements against any inconsistencies. This process goes beyond testing because it is capable of detecting not only fuzzy functional requirements but also non-functional properties that are difficult to test like scalability, efficiency, security etc. At the same time, it is much powerful in reviewing the architecture and design documents or prototype. The inspection process is adopted by many companies like IBM that reported that “1 hour of inspection can save 20 hours of testing and 82 hours of rework”. Also Raytheon, a defense contractor company, reported its effectiveness in reducing the overall cost of fixing defects and rework by a minimum of 20% and effort by 80%. The inspection process has plentiful benefits. Some of which are:

1. Detecting defects easily while working on novel ideas with no preconceived idea about its correctness. 2. Knowledge sharing regarding designs and specific software artifacts 3. Find flaws early before coding can dramatically reduce cost of fixing them. 4. Reduce the rework and testing effort and thus the overall development effort.The inspection is a multistage process (as shown in figure 4) [8] that involves a small team of trained participants (including testers, developers, project manager and SRS document’s authors as well as some experts who worked on similar products) who carefully examine the initial work product for defects and improvement opportunities.

22

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

Figure 4: Inspection process stages

Figure 5: Entry Criteria Matrix Chart 23

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

In the railway system, ystem, an inspection meeting can be conducted with the station labors, on on-site managers, train drivers and other stakeholders to validate the the SRS document and to get their feedback on the initial prototype that simulates the actual system through the inspecti inspection phases: planning, overview meeting, preparation, inspection meeting, rework and follow-up. follow up. This pprocess may need to be repeated multiple times for more accurate results and measurements measurements. In the beginning of the inspection meeting, an entry criteria was filled by 10 inspectors (marked as Innumberin in table 2) to evaluate the SRS document accuracy against against given measures [8] and the result of their evaluation can be seen in the entry criteria criteria matrix of table 2. Figure 5 summarizes the inspection results shown in Table 2. Table 2: Entry Criteria Matrix In-1

In In-2

In-3

In-4

In-5

In-6

In- 7

In- 8

In--9

In-10

conforms to standards and business need Spell-checked No layout error Reference documents are available Requirements are Line numbered All open issues are marked as TBD No > 3 defects in 10 minute

The reviewers then evaluated each functional and non-functional non functional requirement during the inspection meeting and only the requirements that are well written to reflect the business needs and that conform to safety standards were approved and the rest were rejected rejected temporarily to be adjusted in the new version of SRS. The result of inspection meeting reflects how powerful the inspection process in discovering defect early in the development process to avoid the high cost of change if they were discovered later. As a result of the railway project’s inspection meeting of the SRS document, 14 functional requirements (67%) out of 21 and 30 non non-functional functional requirements (83%) out of 36 were accepted as shown in figure 6 and 7 respectively. The rest will need rework to to meet user expectations that were documented as part of the inspection process.

24

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

Figure 6: Inspection result on functional requirements

Figure 7: Inspection result on non-functional requirements

Figure 8 shows the overall inspection process effect on the SRS document and the amount of defects that were discovered during the meeting to refine the requirements and enhance the overall quality of the requirements documents. As you may notice, there was no requirements that are accepted with minor adjustments because inspection process limits the reviewer’s decision to only success or failure which reflects exact number of requirements that needs a rework to match the business need.

25

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

Figure 8: Inspection process result on SRS document

5. CONCLUSION Requirements elicitation is a collaborative decision-making activity involving users, developers, and customers. The requirements elicitation approach is dependent not only on the diversity and experience levels of these cross-disciplinary sources of requirements, but also the type of system being formulated, which ranges from a fully understood to a new, novel and critical one. In this paper, the strategy presented to elicit requirements for critical systems was based on the face to face communication by conducting interviews with the involved stakeholders to know their needs and be more familiar with the problem domain by clarifying vague requirements. The approach also advocates the synthesis of new technique known as Goal oriented modelling, KAOS into an elicitation approach that can be instantiated to address the attributes of a critical systems like the railway system. This research paper also proposes a suitable approach to validate functional and non-functional requirements to produce error free systems using the formal inspection review process that can save a lot of effort by adopting it for validating the requirements.

REFERENCES [1] Kotonya, G. and Somerville .I., “Requirement elicitation and Analysis. In Requirement Engineering processes and Techniques”, PP- 29, New York: Wiley, 8th edition,1998. [2] Christel MG and Kang KC, “Issues in requirements elicitation. Carnegie Mellon University Technical report, CMU/SEI-92-TR-012, 1992.

[3] Aldrich, J. (2007), “Software Inspection”, Lecture presented at Analysis of Software Artifacts in School of Computer Science, Carnegie Mellon University. [4]

Somerville, "Software engineering", 8th edition, Addison Wesley.

26

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016 [5] R. Darimont and A. van Lamsweerde, "Formal Refinement Patterns for Goal-Driven Requirements Elaboration," 4th ACM Symposium on the Foundations of Software Engineering (FSE4), No. 179-190, 1996. [6] Chung, L. (n.d.), “Goal-Oriented Requirements Engineering (GORE): KAOS. Lecture”. [7] Syed, Liyakathunisa. (n.d.), “Requirements Modelling, Lecture presented in Prince Sultan University”. [8] Syed, Liyakathunisa. (n.d.),“Requirements Verification and Validation Techniques, Lecture presented in Prince Sultan University”. [9] Aybuke A. and Wohlin C, “The fundamentalnature of requirements engineering activities as adecision-making process. Information and SoftwareTechnology”, pp. 954-954, 2003. [10] Bourque P. and Dupuis R., “Guide to theSoftware Engineering Body of Knowledge”, IEEEComputer Society, 2004. [11] Friedrich W. R. and Poll J. A.V.D, “Towards aMethodology to Elicit Tacit Domain Knowledge fromUsers”, Interdisciplinary Journal of Information,Knowledge, and Management, Vol. 2, 2007. [12] Ananda Rao and M.Gopichand, "Four Layered Approach to Non-Functional Requirements Analysis", IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 6, No 2, November, ISSN (Online): 1694-0814, 2011, www.IJCSI.org. [13] Chung, L., Nixon, B., Yu, E. and Mylopoulos,J., “Non-Functional Requirements in Software Engineering” , Kluwer Academic Publishers, 2000. [14] Kavakli, E. “Goal-driven requirements engineering: modeling and guidance,Doctoral dissertation, the University of Manchester, 1999. [15] Rolland, C., “From conceptual modeling to requirements engineering”, in Conceptual ModelingER, pp. 5-11, Springer Berlin Heidelberg, 2006. [16] E. Knauss, C. Boustani, T. Flohr, “Investigating the impact of software requirements specification quality on project success”, in Proceedings 10th International Conference on Product-Focused Software Process Improvement, Oulu, Finland,Lecture Notes in Business Information Processing, vol. 32, 2009, doi:10.1007/978-3-642-02152-7,PROFES 2009, Springer. [17] J. Marchant, C. Tjortjis, M. Turega, A metric of confidence in requirements gathered from legacy systems: two industrial case studies, in: Conference on Software Maintenance and Reengineering (CSMR’06), pp. 355–361, 2006. [18] G. Ruhe, A. Eberlein, D. Pfahl, Quantitative WinWin: a new method for decision support in requirements negotiation, in: Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering (SEKE ’02), Ischia, Italy. [19] K. Boness et al., “A method for assessing confidence in requirements analysis”, Inform. Software Technol., 2011, doi:10.1016/ j.infsof.2011.05.003

27

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016 [20] Van Lamsweerde A , “Engineering requirements for system reliability and security”, in: Broy JGM, Hoare C (eds) Software system reliability and security, ser. NATO security through science series-D: information and communication security, vol 9. IOS Press, pp 196–238”, 2007. [21] Ashworth, C. M. Using SSADM to Specify Requirements. In IEEColloquium on ‘Requirements Capture and Specification for CriticalSystems’ (Digest No. 138), 3/1-3/3. Institution of Electrical Engineers,November 1989. [22] Elsayed, H. & AlTurki, A. (2015). Systems and Software Requirement Specification (SSRS) for XYZ Company. Unpublished manuscript, Alfaisal University. [23] Ahmed, A. (2015). Professional Practices and Documentation. Unpublished Manuscript, Alfaisal University.

ACKNOWLEDGEMENT A special thanks to Dr. Liyakathunsia Syed, Assistant professor in Department of Computer Science at Prince Sultan University, whose insight and expertise provided, greatly assisted this research. Her review comments were very helpful in improving the earlier version of the manuscript.

Authors Ms. Hoda Ahmed Galal Elsayed is a Research Scholar and Master’s student in Software Engineering at PSU, graduate at Alfaisal University with a Bachelor Degree of Software Engineering in 2015, and a 1st award winner in software Engineering during the 1st Engineering Expo organized by ABB. She had her training in Oracle Saudi Arabia in 2014. Dr.Liyakathunisa Syedis currently working as Assistant Professor in College of Computer and Information Sciences, Prince Sultan University with more than 15 years of academic and research experience. Dr.Liyakathunisa received her Ph.D. from Visveswaraya Technological University, INDIA and Fellowship in Teaching and Learning from Higher Education Academy, United Kingdom (U.K). She is Vice Chair of Saudi Arabia ACM Professional Chapter; it is the first professional chapter in entire Saudi Arabia. She is the Recipient of Google India Women in Engineering Award in the year 2011, in recognition of the outstanding contribution made in the field of Computer Science and Engineering. She has more than 30 Research papers published in International Journals, International Symposiums and International Conferences. Her area of research is Software Engineering, Computer Vision, Artificial Intelligence, Digital Image Processing, Data Warehousing and Mining.

APPENDIX A: Sample Interview with railway project stakeholders The purpose of this interview is to identify some vague requirements related to the system to be implemented. This sample interview can be conducted with ministry of transportation representatives, railway managers, suppliers, some in-site workers, possible suppliers and sponsors. The meeting starts when all involved parties introduce themselves and then requirements engineers can ask questions related to the domain problem [23].

28

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

Questions to stakeholders 1. Are the crossways one way or two ways and what are their dimensions? 2. What is the average speed of trains? 3. Where do you want the railway control unit and the data center to be located? 4. Is there any previously implemented system? If yes, can we access it? 5.What is the average of accidents that took place last year? 6.What was the main reason behind those accidents? 7.In which season does the accidents usually happen? Summer, autumn, winter, spring. 8.What kind of tools do you need to facilitate the system control? 9.What type of accidents usually take place? 10.Can you provide us with the trains’ schedule? If not, how can get these information? 11.How many crossways in the country and how many workers exist in each site? 12.How is their educational level and will they need to be trained? 13.Who is responsible for the scheduling process? If “IT”, can we coordinate with them? 14.Do you have any special concern related to the system quality? 15.Do you prefer the onsite testing or simulations? 16.What is the timeframe of this project?

Stakeholders’ Answers 1. 22 crossways out of 25 across the country are 2ways with dimensions 100 ft x 200 ft. 2. The average speed of trains is 300 km / hour but it’s much less when they approach the crossing level. 3. The control unit should be located in the headquarter station on the capital city but the data center may be located somewhere outside the country or on cloud to keep the data safe as much as possible. 4. No actually, there was no previous system as the whole process was done manually except for having an online scheduling system accessed to control the trains timings to avoid conflicts on the crossway. 5. Last year, an average of 35 accidents happened and they vary in their severity measures. 20 were of High risk, 7 of medium risk and 8 with low risk but that seems to be continuing with an increasing rate so we need a solution that minimize or prevent such risks. 6. Oh dear... Many reasons! Some were due to bad weather conditions that led to destructing some barriers and road parts and manpower was a big obstacle on the way because they can’t control the barrier manually in such weather conditions according to the labor law. Others were a result of people breaking the rules and crossing the level but that was nearly 10% only of the accidents that happened. 7. Nearly 75% of the accidents happen during the winter and the rest are divided on the other seasons of the year. 8. A camera would be good to have a better controls over the barriers and should be fixed in a constant distances from left and right side of barriers. Also, new set of traffic lights and maybe some alarm devices for visually disabled people. Sensors and radars may be added to track speed and distances from the barriers. All trains will need to be updated to have touch screens through which train drivers can communicate with the system. Sensors’ health should be detected by RGB levels on system. 29

International Journal of Software Engineering & Applications (IJSEA), Vol.7, No.1, January 2016

9. Usually severe accidents are due to a crash between large vehicles like buses or trucks and trains and many other accidents were reported for pedestrians killed under the trains’ wheels when they badly decided to cross the level in the wrong timing. 10. Sure, we can provide you with these information. 11. There are nearly 25 crossways across the country and around 15 employees in each site. 12. Their educational level is considered medium or low so yes of course, they will require at least 2 months of training to be familiar with the new system. This training should be planned for prior to the project delivery. 13. Of course, you can have access to it through our IT team; we can organize a meeting with them for you soon. 14. Yes actually, we need the system to be accessible via fingerprints of stations’ supervisors and train drivers for security reasons. Also, it’s important to make the system accessible 24 hours with quick transformation of data among different interfaces. The system data should be updated every 15 seconds to track the sensors functionalities. 15. Unfortunately, we can’t provide on-site testing because trains can pass any time. That will require us to stop or cancel all trips in specific hours each day and that will definitely have a bad consequences on the goods’ transportation and passengers too. A real time simulation is preferable actually. 16. As you may have noticed, the system may change the entire railway structure so we are considering this and we are expecting that it can be done in 2 years from now.

30