Analysis of Micron Software - Case Study Example

MICROFINANCE MANAGEMENT SYSTEM REG Number TASK Software Specification 1. Introduction The project involves the design and development of a software system referred to as Micron, for the management of a microfinance institution. The system performs the tasks of receiving member contributions on a monthly basis and recording them in a database. It also does the issuing of lending to members and then does the recovery (Bell 2008, p.23). The majority of lending groups continue to perform their operations on paper based management, which leads to loss of data, destruction and mismanagement such as alterations and forgeries. The introduction of the Micron Software solves the situation by creating an interface through which the users of the system can maintain data for accountability, integrity, reliability, transparency and foe easy audit (Leffingwell 2000, p. 28). The system will therefore solve the challenges with paper based operations and produce fast tracking of reports in a customized manner. It will reduce or possibly eliminate the cases of data loss and mismanagement. 1.2. Outline of Specifications 1.2.1. Functional Software Requirement The system to be developed in this project is expected to be interactive in accepting and processing the user input data, and generating output in form of dialogues and reports. The system has to be easy to study so that the clients, operators and users can learn it easily. Even without user guide or progress documentation, the system requirements have to be clear and comprehensive. There have to be consistency in the system functions such that it performs all the action indicated. For example, if the button is indicated as “Close”, then it has to close the current form. 1.2.2. Data Requirement Overview The system is expected to accept data input from the user, perform financial operations and then generate an output from the product and the data kept in its historical database. The system also must do data validation during the input to ensure that each field accepts the right form of data. For example, the field for date should not accept any form of data apart from date. 1.2.3. Constraints, Assumptions and Dependencies The system has minimum requirement of features and hardware properties which limits its development for example, the size of the memory available, the speed of the processor and the size of the hard disk. The constraints can be caused by failure to meet the basic requirements of the development environment. Other constraints arise from information policy, system response times, and system interfacing with other related application software, the capacity of the networks and compliance issues. The minimum requirement of memory size for example is a RAM of 2GB and hard drive of 500GB. 1.3. Product Perspective In the product perspective, the product of this software is independent and self contained because of the consolidation and integration of all the components. The components required for this system are segment into three software specifications, the software and the hardware and software. Because of the requirement of the interface, the third specification outlined here is the user or the interface requirement. The functionalities of the software are supported by the appropriate integration of the components as shown in figure 1 below: Figure 1: Integration of the Requirement Components. 1.3.1. System Interfaces The system will operate using a graphical user interface 1.3.2. Interfaces The software ought to being dynamic and interactive software, with which the user will communicate through the hardware components. 1.3.3. Hardware Interfaces The software has specific requirements on the properties of the hardware devices to function adequately. For example, the hard disk space has to be at least 500GB to accommodate the increasing volumes of data being captured. 1.4. Software Project Specifications The requirements of this system are segmented into 3 categories, software requirement, hardware requirement and user Requirement. These are specified as shown below: 1.4.1. Software Requirement Specification The software requirement in this project includes the development environment, which in this case is Visual Studio, which is easier to use (Laplante 2009, p. 43). Visual studio is ideal because its executable application is lighter, faster and has a friendlier interface, apart from the fact that it has its inbuilt reporting tool (Roger 2003, p. 41). The database management tool for the project is Microsoft access, owing to the portability of the system and the size, unlike Oracle that requires a specific server set up. The system requires a documentation tool, preferably MS Office 2010, with MS Word, Excel and PowerPoint. Additionally, the system requires an external code editing tool to avoid a direct interaction with the source code (Gottesdiener 2009, p. 34). In this case, the system requires notepad. The operating system for the development of this system is Windows 7 and any equivalent. However, the executable application will be able to operate from any Windows Platform. The summary of the Software requirement is presented in table 1 below: Sub-Category Selected Tool Development Tool Visual Studio 6.0 Database MS Access Documentation MS Word, PowerPoint and Excel Alternative / External Code Editor Notepad Operating System Windows 7 Table 1: Software Requirement Specification 1.4.2. Hardware Requirement Specification The hardware requirement for the development of the Micron system principally includes a fully powered personal computer or a laptop. It will also require an external storage for portability and back up purposes (Freeman & David 2004, p. 19 - 21). Additionally, the Micron System will have to operate on a network platform, to enable the entire organization users to run multiple user sessions at the same time (Lyytinen et al Lyytinen, p. 49). The hardware requirement is specified as shown in table 2 below and with the following properties. Hardware Component Properties Hard Drive 500 GB and Above Memory (RAM) 2 GB and above Processor Speed 2.8 GHz and Above Monitor Flat screen LCD 15 inches and above External Hard Drive for Storage 10 GB and above Networking Hardware Network cables Table 2: Computer hardware Requirement 1.4.3. User Requirement Specification The user requirement for the Micron Software implies the ability of the user to use the system. The fundamental requirement in this is that the user ought to be computer literate, and be able to study and understand the flow of activities in the system (Dijkstra 1988, p. 52- 54). Secondly, Micron requires technical and administrative support from the developer to the end users during the post implementation stage (Leffingwell & Widrig 2003, p. 54). 1.5. Factors Leading to the Selection: Use of Microsoft Access Data Base There is a wide range of choices of database tools to use in the design of the Micron Software, such as SQL server, MySQL and Oracle. The choice of MS access for the Micron system is driven by the following properties. 1.5.1. Portability and Simplicity The reason for choosing MS access is because it is portable and does not require any complicated server configuration to operate. This makes the connectivity between MS Access and the Visual studio tools faster. 1.5.2. Technical Vendor Support Secondly, being a Microsoft product, it receives support from Microsoft Corporation online, on the use of various components (Cockburn 2001, p. 30). There is sufficient information on the global network for support of the use of Microsoft Access. 1.5.3. Ease of Conversion The data stored in MS access database can easily be migrated to a different database option whenever there is need. This can be done through export and import functions in the database tools. 1.5.4. Access On the Network The database is sharable on the network and can therefore, be accessed by the users from any location through the user interface developed in the Visual Studio platform. In other databases, the configuration is done in a specific server and cannot be moved. 1.6. Full Software Project specification 1.6.1. Software Interfaces The Micron System will link directly to the database from the user interface. Both the design tool (Visual Studio) and then Access Database will interface with the Windows 7 operating system as well as any other element of software that Micron requires (Carroll 1995, p. 48). For executing of parallel transactions, the cluster will use a sharable folder on the server. The application in the user computers will map directly to the server directory. 1.6.2. Administrator Interface The least requirement of administration is that the administrator ought to interact with the Micron system via the Windows 7 Graphical User Interface objects. Additionally, more commands enable the administrator to perform the following tasks: Confirm the status of each user, whether active or Deactivated Confirm the history of system usage by each user Confirm the status of all transactions posted Confirm the validity of the data for each transaction Change the structure of the database and the user interface Change the scheduling rule for all transactions Update the transactions in the database, cancel transaction, and produce report of all transactions 1.6.3. Hardware Interfaces All interfaces of the hardware components for the Micron system will be running on the Microsoft.Jet.OLEDB.4.0DB connectivity Engine. For that reason, it will incorporate interfaces for the following: CPU use Memory use Creation of Swap File Network data transfer and Communication 1.6.4. Communications Interfaces Micron will make use of the communications architecture from the Visual Studio and the database connectivity Engine. It will not require having any complicated and unique communication interface as required in other high level database tools. 1.6.5. Licensing Requirements Micron will be presented under the licensing of the company that developed it; hence it will not be an open-source system. Predominantly, the scope of Micron system relates to the microfinance product structures for the software project to be live. It emphases on the developing firm, the beneficiaries and the applications, which enable online transactions, contribution and issuing of funds to the members (Bourque & Fairley 2014, p.43). These specific software requirements of Micron Software to be produced also applied choice of the commercial products of software (Wiegers 2002, p. 49). The same standards of software tools were used in the creation of software specifications directly and in the modeling of the standards for the microfinance organizations. 1.6.6. Other Specific Requirements The specific software requirements for the Micron System are about the functionality of the software. 1.6.6.1. Functionality The functional software requirement of the Micron System is refined in the sequence diagram as well as the use case diagrams to articulate the Micron system functional requirements. All functional requirements for the Micron System are traced with the application of tractability matrix. 1.6.6.2. Software Functional Requirement Specification The Micron system will present all products to be configured The Micron system will permit user to choice the transactions to perform The Micron system will present all available project tasks to perform The Micron system will enable its users to generate the reports required for audit The Micron system will inform the user about the inconsistency in the present data. The Micron system will enable the user to update the data once inconsistency is noticed The Micron system will give opportunity for the user to confirm actions upon the completion of the present transaction 1.6.6.3. Provision of Search Facility The Micron system will let the user to provide the search data on the front-end interface screen. The Micron system will let user to choose multiple selections on the form for search The Micron system will show all the records that match the search criteria The Micron system will let user to traverse from one search result to another The Micron system will inform the user when it fails to get the matching search data record 1.6.6.4. Maintain Member Profile The Micron system will let the administrator to create the new members and set their credential The Micron system will validate user authorizations to look at the profile The Micron system will let users update the information in the Profile 1.6.7. System Usability 1.6.7.1. Micron GUI User Interface The Micron System will present a uniform image and texture between the data forms. The system will present a unique identifier every transaction and data records The system will provide icons as well as toolbars for the various functionalities 1.6.8. System Accessibility The system administrator will control the access to the system through a central user management framework. 1.6.9. System Reliability and Availability 1.6.9.1. Dedicated Server The system will run on a server permanently dedicated for its functionality to provide data for all the client requests from various computers. The Micron system will provide back-up for the databases storage at remote locations for data recovery (Wiegers & Beatty 2013, p. 39). 1.6.10. System Security 1.6.10.1. Data Transfer The system will require password from the users to log them in and out. The system administrator will have to deactivate the external storage media on all computers on the entire network to prevent the copying of data by unauthorized people. The administrator will only grant access to users with proven authorities. Additionally, there will no access to external global email services. This will eliminate the possibility of a user sending sensitive customer information to third parties. 1.6.10.2. Data Storage The system user credential will be stored in the database, from where the system will retrieve them. Each user is given the provision for creating their secret passwords which the form will not display at any time. The authenticated system administrators will be the only people to access the back-end of the system. 1.6.11. Interfaces The Micron system is supported by many interfaces including the User Interface, the Software and the Hardware Interface. 1.5. Project Plan for the Software Project The plan for development of the Micron System is broken down into 4 main stages, the System Design stage, development and testing stage, the implementation stage and post implementation review stage. 1.5.1. System Design In this stage, the system will be designed both in the layout of the user interface and the data base structures. The connectivity to the database from the user front –end interface will then be defined. The design will determine the task flow and the treatment of data in the system. The workflow will be defined using use case diagrams, flow chart and relational Database structure. 1.5.2. Development and Testing The next stage will involve the coding of the system to provide the relevant functionality of every GUI object (Booch et al 2004, p.56). The system will only do what the coding states. As the code work proceeds, each module is tested to confirm whether it functions or fails. The testing is done using dummy data, which will eventually be deleted when the system goes live. 1.5.3. Implementation Once the testing is complete, the system is deployed, ready for the actual implementation. The implementation uses live data for the members of the microfinance lending group. 1.5.4. Post Implementation Review After the implementation, there will be a review of the system to assess the functionalities, successes, strengths, weaknesses and failures to support the mitigation of Runtime errors at the same time. The review is accompanied by a documentation to demonstrate appropriateness of the techniques in the development of the project (Suryanarayana 2014, p. 41). The post implementation review will discuss the relevance of the project and suggest the ways of improving and developing the system further for the future usage. 2. TASK 2: Implementation of the Software Specification 2.1. System Design The design of the system is broken into three sections, structural design, user interface design and database design. The structural design is presented in the use case diagram in figure 1 below and in the flow chart in figure 2 below. The use case shows the interaction between the system and various users. 2.1.1. Structural Design 2.1.1.1. Use Case Diagram Figure 2: Use Case Diagram for the Micron System The administrator has access to all the system components such as the database, the user interface and the report generating component. The reviewer is able to observe the performance of the system interface and the report to do system audit. The members are only able to receive reports for the transactions carried out but not performing any action on the system. Inputters are able to log into the system, create new members and input data for the transactions. External support team is able to access any part of the system assigned to them for any reason. 2.1.1.2. Work Breakdown Structure (Gantt Chart) the work breakdown is shown in the Gantt Chart in table 3 below. Activities Months ID 1 2 3 4 5 6 7 8 9 10 11 12 1 Preliminary Study 2 Software Requirement Specification 3 Hardware Requirement Specification 4 User Requirement Specification 5 Conceptual l Logical Design 6 Structural Design 7 System Interface Design 8 Coding 9 Testing 10 Deployment 11 Implementation 12 Post Implementation Assessment Table 3: Gantt chart 2.1.1.3. Flow Chart The flow chart in figure 3 below shows the intended flow of activities from the point of logging in to the selection of transactions to the final stage of performing the transactions. Figure 3: Flow Chart of System Events The initial activity is the log in into the system. The next step is the entry of the member number before selection of any action from the menu. Once the member number is validated, the user can select the required menu and perform the transaction. 2.1.2. User Interface Design The interface of the system is designed in Visual Studio 6.0. The user interface is shown from figure 3 to figure 11 below. Figure 4: Log in Form Figure 5: User Creation Form Figure 6: Main Menu Figure 7: Member Account Registration Form Figure 8: Share Contribution Figure 9: Loan Issuing / Loan Recovery Form Figure 10: Payment / Share Contribution Receipt Figure 11: Loan History Statement Figure 12: Share Contribution Statement 2.1.3. Database Design The database was designed in Microsoft Access as previously stated. Each of the structure of the tables is presented below, with the table names, field names and the description of the datatypes of each field. 2.1.3.1. Transaction Table Transactions TransNo Number AccountNo Number AccountTitle Text Dated Date / Time Particular Text ChequeNo Text Debit Number Credit Number Balance Number InterestRate Number interestCollected Number Table 4: Transactions Table 2.1.3.2. Users Table Users UserName Text Password Text Domain Text Table 5: User Management Data 2.1.3.3. Expenditure Table Expenditure Date Date / Time Particular Text Amount Number Table 6: Expenditure Data 2.1.3.4. Banking Table Banking TransNo Number Date Date / Time Particulars Text OtherDetails Text MoneyIn Number MoneyOut Number Table 7: Banking Data 2.1.3.5. Member Contribution Contribution TransNo Number Cname Text AcNo Number Amount Number CDate Date / Time Balance Number Table 8: Member Contribution Data 2.1.3.6. Member Account Creation Member_Account_Creation AccountNo Number AccountTitle Text Fname Text ContactTitle Text Address Text Region Text City Text PostalCode Text PhoneNo Text MobileNo Text Email Text OpeningDate Date / Time AccountType Text InitialDeposit Number Table 9: Member Account Creation 2.1.4. Data Entity Relationship The relationship between the tables is presented in figure 13 below. Figure 13: Data Entity Relationships 2.2. User Manual 2.2.1. Log In Figure 14: Log In Form Enter the user name and Password. For this demonstrattion, username is “coloo” and password is “7777”. Click on the log in Button. You will see the main form opening as shown in figure 15 below. Figure 15: Main Menu Screen Click on the “Create Member” Button. The form for creating members appear as shown in figure 15 below. The member number is automatically generated by the Micron System. 2.2.2. Creation of New Member Enter the member details in the fields provided and click on the “Save” button. Figure 16: Member Creation The form for member registration saves the new member and opens up the share registration form with the amount of initial deposit to be registered. This is shown in figure 17 below. Place the cursor in the textbox labelled “Account”. Press the tab button on the keyboard and it will display the name of the registered member. Figure 17: Registering Initial Deposit in Contribution Click on the “Save” button. The dialogues in figures 18 and 19 below apear. Click OK to Save. Figure 18: Confirmation of the Save Action Figure 19: Action Completed Click on the button labelled “Close”. The dialogue in figure 20 below appears. Click on OK to close. Figure 20: Confirmation of Close Action 2.2.3. Loan Disbursement Enter the member number in the account number field in the main menu form. Click on the Loan Issue button and the loan issuing form appears as shown in figure 21 below. Figure 21: Loan Issuing Form Enter the details as shown in figure 23 below and click on the “save” button. You can also click on the “Receipt” button to view the printable receipt as presented in figure 23 below. Figure 22: Posting the Loan Disbursement Figure 23: Transaction Receipt If the computer is connected to a printer, click on the “Print” button and the receipt will be printed on a physical paper. Click on close button to close the receipt. 2.2.4. Loan Recovery After the disbursement of the loan, enter the member number in the Account Number field. Click on the Repayment button and the form appears with the member’s details as shown in figure 24 below. Figure 24: Loan Repayment Click on the receipt button to view the transaction receipt. Figure 25: Loan Repayment Receipt 2.2.5. Share Contribution Enter the member number and click on share contribution and the form opens up as shown in figure 26 below. Press tab and enter the amount. Click on save. You can search for a transaction by entering the transaction number in the “Transaction No” field and clicking the “Search” button. Figure 26: Further Share Contribution 2.2.6. Banking Transactions Click on the button for Banking or withdrawal depending on the requirement. The forms open as shown in figure 27 and 28 below. Enter the details and clisk on the save button. Figure 27: Banking Form Figure 28: Bank Withdrawal 2.2.7. Viewing Balances Click on the Balance Summary Button and view the balances as shown in figure 29 below. Figure 29: Balances View 2.2.8. Report Viewing Click on the radio button “Between” and set the date “From” and “To” and click on either Share statement, Loan Statement and member list. The reports appear as shown in the figures 30 and 31 below. Figure 30: Share Statement Report Figure 31: Loan Statement Report 3. Task 3 – Evaluate the software project 3.1. Documentation of Software Evaluation In the actual sence, the system was reviewed and evaluated systematically. The evaluation revealed successes, failures and areas of improvement. 3.1.1. Success and Strengths of the of the Project 3.1.1.1. Multiple Functions One of the success factors of the system is that it was able to register new members, edit the existing member, register shares, issue loans and repayments. Additionally, it was able to operate other transactions such as banking and expenditure. At the click of a button, the system generated the balances for all the transaction accounts on the screen. 3.1.1.2. System Data Security With regards to security, the system controlled the acess to data and the sensitive modules through the user administration. Without a password given by the administrator, it is difficult to penetrate through the system. Additionally, the system restricted functionalities such that only users with administrative privileges can create and edit users. 3.1.1.3. Transaction Confirmation The system was able to present the confirmation of transactions through issuance of receipts and also through the reports generated within a range of dates. The members are therefore able to present querues concerning their transactions. 3.1.1.4. Minimum Error Rates The test did nor reveal any runtime error because the system was developed with error handling machanism. This increased the reliability of the system for fiunancial calculations. 3.1.1.5. Compartibility with the Operating System The system is able to run on many operating systems so long as Microsoft Visual Basic 6.0 is installed in it. This is because the database connectivities depends on certain drivers and libraries in the Visual Basic development Platform. 3.1.1.6. Confirmation of Transactions Whenever a user is about to perform a destructive action, the system provides confoirmation of the transactions through dialogs. For example, when updating data, the system asks, “Are you sure you want to update the data”. This prevents the user from performing unintended sensitive actions. 3.1.2. Failures and Weaknesses of the Project Despite the strengths of the system, there were a few weaknesses as discussed below. 3.1.2.1. Inconsistency in Visual Image From the evaluation carried out, there was no consistency in the properties of various objects used. For example, the use of colors in the forms were different. As some form used blue colors for labelling, others used green, red and grey. 3.1.2.2. Lack of Help facility The system lacked a help facilty. There was no reference point to which a user could refer for any technical challenge, except for the user manualk that could not exhaust every functionality. 3.1.2.3. Tab Order Mismatch In the member registration form, there was a mismatch in the tab orders. This makes it difficult to use keyboart tab key as a shortcut operation. 3.1.2.4. Lack of Reversal Some of the transactions could not be reversed, as the best practice in system development provides. There ought to be a mecahnism of reversing the transactions whenever an error is realised. For example, there ought to be a way of deleting a member who has exited the group. The system did not have the provision for deversal except in the member registration and share contribution form, where a user can edit and update the data. 3.1.3. Areas of Future Improvement The review revealed that the system worked as expected. However, there are many areas that can improve in the future as discussed in this section. 3.1.3.1. Conversion to Online Functionality Many systems in the modern Information Technology Industry operate on an online platform. It will be an ideal plan to convert the system into a web based platform to be able to operate in a wider network. 3.1.3.2. Introduction of the Help Function The system has the need to introduce the help facility. This can be done by writtng the help information in the shalom help program and integrating it into the system, in the main menu. 3.2. Significance of the Project 3.2.1. Easy Application of the System The system is easy to use because it is labelled in a simple language. In addition, the labels and captions are relevant because the objects perform the exact tasks indicated in the labels. 3.2.2. Traceable Audit Every transaction is registered under a unique identifier, which makes it easy to trace the data concerning avery entity. For example, the members are uniquely identified through the member account number, transacttons are easily identified through the transaction numbers and the users are identified by unique user names. 3.2.3. Search of Data The forms have the search capability, which enables the users to enter the unique identifier and search for the required data. Foe example, the user enters the transaction number in the share contribution form and clicks on the search button to search for the existing transactions. Every transaction in the system relates to the member account number in the main menu form, without which the system rejects the transaction. 3.2.4. Balance Summary The system is helpful as revealed by the review, in the presentation of the summary of the financial balances. It is therefore, notnecesary for the finance department to do a paralel manual calculation of the same balances. 3.2.5. Multipple Transactions When the system is configured to operate in a networked environment, the users from many computers can open it and log in at the same time. This enables them to post a large number of transactions at the same time, hence it helps leverage on time and operational cost. 3.2.6. Automatic Number Generation The system automatically generates the registratiuon numbers and the transaction numbers for all transactions. The users do not need to master the series of numbers to decide on the numbers to assign, as would be tha case in a manual financial system. 3.3. Justification of the System Application The application is appropriate for this project because it was developed in a typical environment that represents the presence of integrated computer system. With the graphical user It also has the ability to provide user feedback, so that the user can decide on the events to execute. Secondly, it is compartible wilth the hardware component and the user has adequate experince and knowledge of the interface. 3.4. Reason For Choosing Micron The Micron System was selected because it seemed appropriate as a comprehensive system that can be placed in an actual use. Indeed, Micron, can work in a Micro Finance Operational Environment, and serve the purpose of financial management. The added advantage of Micron sytem is the fact that it integrates to a database, such that the records are stored for all the transactions. Thirdly, the source code forr Miscron is easily available for further development and furture modification of the system. This implies that the system has continuity plan and a recovery plan. Finally Micron is developed in Microsoft Products, which enables its users and developers to acqire support services from Microsoft Corportion as the Vendor. 3.5. Conclusion The system was well developed and was able to cover all the stated functionalities in the software specification. However, because of the weaknesses and limitations realized, there is need to improve the system and probably set it on a web based platform. The software specification and system objectives were met and the system will continue to acquire better improvements because the source code is available. References Bell, M 2008, "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons, p. 48. Booch, G et al. 2004, “Object-Oriented Analysis and Design with Applications (3rd ed.). MA, USA: Addison Wesley, p. 34. Bourque P & Fairley RE 2014, "Guide to the Software Engineering Body of Knowledge (SWEBOK)". IEEE Computer Society. Carroll, ed., J 1995, Scenario-Based Design: Envisioning Work and Technology in System Development. New York: John Wiley & Sons, p. 54. Cockburn, A 2001, Writing Effective Use Cases. Pearson Education, p. 39. Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science", p. 52 - 54. Freeman P & David H 2004, "A Science of design for software-intensive systems". Communications of the ACM 47 (8): 19–21 [20]. Gottesdiener E 2009, The Software Requirements Memory Jogger: A Desktop Guide to Help Business and Technical Teams Develop and Manage Requirements. Addison-Wesley. Laplante PA 2009, "Requirements Engineering for Software and Systems". CRC Press. Leffingwell D 2000, Managing Software Requirements: A Unified Approach. Addison-Wesley Professional, p. 43. Leffingwell, D & Widrig D 2003, “Managing Software Requirements: A Use Case Approach” (2nd ed.). Addison-Wesley. Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W 2006, “Design Requirements Workshop (LNBIP 14), pp. 103–136, Springer-Verlag, p. 98. Prause, C et al. 2008, "Managing the Iterative Requirements Process in a Multi-National Project using an Issue Tracker". IEEE Computer Society. Pressman, R 2010, “Software Engineering: A Practitioners Approach”. Boston: McGraw Hill. p. 23. Ralph P & Wand, Y 2009, “A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–136. Springer-Verlag, p. 99. Roger S P 2003, “Software engineering: a practitioner’s approach”, McGraw-Hill, p. 32. Stellman, A & Greene, J 2005, Applied software project management. OReilly Media, Inc. p. 38. Suryanarayana, G 2014, Refactoring for Software Design Smells. Morgan Kaufmann. p. 58. Wiegers, K & Beatty J 2013, Software Requirements, Third Edition. Microsoft Press. Wiegers, K 2002, Software Requirements (2nd ed.). Microsoft Press. Read More