The assignment is of only 1000 words, not 2000 as mentioned in the pdf.I have attached the assessment brief, module to be referred, sample assessment document & side headings to be used
07/10/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_76466_1&content_id=_7987776_1&mode=reset 1/7 MODULE 2.1MODULE 2.1 Levels and types of requirements and characteristics of good requirements Introduction: You have learnt from Module 1 that requirement is “a statement that identi�es a product or process operational, functional, or design characteristic or constrain, which is unambiguous testable or measurable, and necessary for product or process acceptability” (Dick, Hull & Jackson, 2017). It is important to note that requirements can be categorised into 07/10/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_76466_1&content_id=_7987776_1&mode=reset 2/7 di�erent types. Take Blackboard for example, compare the following two requirements: Requirement 1: This System will enable students to view learning activities; Requirement 2: This System will be reliable and robust. (Note: this is not an example of a good requirement, but it serves the purpose of demonstrating various types of requirements). Requirement 1 and 2 do not appear to describe the same aspect of the System. Requirement 1 is concerned with WHAT the System shall do – its functionalities, that is, what users (or actors in this System) can accomplish with this System. Requirement 2, on the other hand, is concerned with HOW the System shall perform its various tasks. Requirement 2, in a very loose language, requires the System not to fail every so often. You should be aware that there is no consensus as to a single taxonomy of requirement, that is, a requirement may belong to multiple types depending on the ways requirements are categorised. Young (2004) provides a requirement analyst’s view of many of the types of requirement. You are expected to read an extract of Young (2004) (refer to Essential Resources 1). Among various types of requirements, you are expected to understand the de�nition and examples of the following: Business requirement; User requirements; High-level or System-level requirements; Functional requirement; Non-functional requirement; Performance requirements; Interface requirements; You will also need to familiarise yourself with FURPS and FURPS+. Both acronyms refer to a set of requirement categories; the latter is an extension 07/10/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_76466_1&content_id=_7987776_1&mode=reset 3/7 of the former. Refer to Essential Resources 3. The quality of requirement should not be overlooked. What are the characteristics of a good requirement? Consider the following requirement statement: “The System shall handle many transactions per second.” That requirement cannot be regarded as a good requirement because, among many other things, it is not veri�able/testable. What does it mean many? How many transactions is many? Such requirement engender confusion and much necessary debate in the later stage of development. What are the criteria for a requirement to be good? Good requirements should have the following characteristics: Unambiguous Testable (veri�able) Clear (concise, terse, simple, precise) Correct Understandable Feasible (realistic, possible) Independent Atomic Necessary Implementation-free (abstract) Consistent Nonredundant Complete You need to read Essential Resources 4, which discusses each of the criterion in depth. Reference: 07/10/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_76466_1&content_id=_7987776_1&mode=reset 4/7 Dick, J., Hull, E., & Jackson, K. (2017). Requirements engineering. Springer. Young, R. (2004). The requirements engineering handbook (Artech house technology management and professional development library). Boston: Artech House. Essential Resources: Young, R. (2004). The requirements engineering handbook (Artech house technology management and professional development library). Boston: Artech House. Retrieved from: https://lesa.on.worldcat.org/oclc/54703038 Read extract from The requirements engineering handbook Read Chapter 4, page 45 – 60. In this short reading, you are introduced to a few requirement taxonomies and a wide range of requirement types. You should pay particular attention to the following types of requirement: Business rules; User requirements; High-level or System-level requirements; Functional requirements; Non-functional requirements; Performance requirements; Interface requirements; Product requirements; On page 56 and Table 4.3 (a-d), Young provided examples of the requirements types discussed this Chapter. These examples will help you understand the otherwise abstract de�nitions and descriptions of requirement types. On page 53 – 54 under the heading “The ‘Ilities’ and Specialty Engineering Requirement”, Young provided a list of quality attributes, for example, https://lesa.on.worldcat.org/oclc/54703038 07/10/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_76466_1&content_id=_7987776_1&mode=reset 5/7 Reliability; Testability; Maintainability; Unfortunately, Young did not provide any further explanations as to the meanings of those “-ability” quality attributes. You will explore the de�nitions of those attributes in a subsequent Essential Resources. YouTube. (2019). What is a Functional Requirement? - Construx Brain Cast. [online] Available at: https://www.youtube.com/watch?v=wbCAiLzOE30 [Accessed 24 Jun. 2019]. This short video explains what a functional requirement is in simple and non-technical language. Stephens, R. (2015). Beginning software engineering (Wrox: programmer to programmer). Indianapolis, IN: John Wiley & Sons. (2015). Retrieved from: https://ebookcentral-proquest- com.ezproxy.laureate.net.au/lib/think/reader.action?docID=1895174 Read Chapter 4 Requirement Categories Section, page 61 – 67. This reading is complementary to Learning Activity 1. Pay particular attention to FURPS and FURPS+ (the list on page 66). Make sure you understand the de�nition of each requirement category listed on page 66 and are able to give examples of each requirement category in relation to a concreate information system. Zielczynski, P. (2019). Requirements Management Using IBM Rational RequisitePro | 1.1 De�nition of a Requirement and a Stakeholder | InformIT. [online] Informit.com. Available at: http://www.informit.com/articles/article.aspx?p=1152528&seqNum=4. [Accessed 24 Jun. 2019]. https://www.youtube.com/watch?v=wbCAiLzOE30 https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/reader.action?docID=1895174 http://www.informit.com/articles/article.aspx?p=1152528&seqNum=4 07/10/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_76466_1&content_id=_7987776_1&mode=reset 6/7 Read Chapter 1.4 in Requirement Management Using IBM Rational RequisitePro Learning Activity: Collaborative learning activity: Once you have read/viewed all essential resources in Module 2.1, you should have a very good idea of the various types of requirements and the characteristics of a good requirement. Now re�ecting on your experience with Blackboard and pretending you are to develop a System, Whiteboard, exactly the same as Blackboard, list Three di�erent functional requirements. What Whiteboard should do? One requirement regarding reliability. How reliable Whiteboard should be? One performance requirement. How e�cient Whiteboard should be? One design constraint. One supportability requirement. How easy should Whiteboard be to support? One physical requirement. Bring your list of requirements to the facilitated class and exchange it with a peer student. Review the other student’s list of requirements, provide constructive feedback as to: whether the requirements are correctly categorised; whether each of the requirements meet the “good” requirement criteria, particular, they are unambiguous testable (veri�able) clear (concise, terse, simple, precise) 07/10/2019 Laureate International Universities https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_76466_1&content_id=_7987776_1&mode=reset 7/7 correct understandable feasible (realistic, possible) independent atomic necessary implementation-free (abstract) Provide your feedback both verbally and in writing to your peer. Note: The Learning activities above are not part of summative/graded assessment; however they are designed to prepare you for incremental graded assessment and expand your learning. These activities encourage a community learning experience between peers, and provide opportunities for facilitators to o�er formative feedback, throughout a module, to the student cohort. 1. Introduction ABC Ltd. ltd is start- up company, which has wonderful idea of an application that will form a bridge between the traders and the customers. This app will definitely work as a transformation for all the traders and the customers as this will promote a job site for them. The app will help to providing the handyman services and trade services to the clients and building up the relations between the clients and tradesmen. The app will majorly promote the services related to home cleaning, heating & cooling system repairing services, gardening, furniture assembly and much more. Whereas, the ABC Ltd. will make this app easily accessible to customers in order to look for a correct trade person and can be contactable on messenger vice versa it be beneficial for the trade person by putting up their profiles on app and look for available jobs, can contact customers. Additionally, ABC will acquire incomes by building up the application and recognizable proof of the business openings from the system from trade services. The purpose of the report is to understand and provide a support to ABC in order to help them developing this “app” by explaining complex concepts of requirements engineering key process and its various elicitation techniques as the objective of the ABC’s app is to connect tradesman and customers. Whereas, this report withheld the establishment of the credentials in requirement engineering, key process required in requirement engineering, elicitation techniques, functional non-functional techniques for the proposed app. 2. Establishment of the Credentials for Requirement Engineering for ABC Pty Ltd It’s a group of three members who are working on this report in order to get this proposed app developed for the ABC ltd. Every member of the group has engineering qualifications with bachelors and master’s degrees. Richa Rani – software engineer and has experience with world famous MNC’s such as Google, TCS as a web-developer. Preetham Reddy – electronic engineer, have been working as an engineer. Ram Bharat – computer engineer and have been working as a computer engineer with world known organisation. These experiences and qualifications play an important role in utilising these experiences while working on proposed app of ABC ltd. 3. Significance or importance of the Requirement Engineering ABC Pty Ltd The requirement engineering is the most significant period of SDLC known as software development life cycle. As this stage is utilized to decipher the loose, and to complete the incomplete parts or software deficient needs and requirements of the potential clients of programming into complete, exact and formal needs (Woods & Hollnagel, 2017). The needs go about as the agreement between the users and the developer. Thus, the significance of Requirement Engineering is huge while developing software as required with less errors on the first stage of developing. Since Requirement Engineering (RE) has incredible job in various phases of the SDLC, it is known that software development is critical. Therefore, there are various of methodologies and approaches exist in requirement engineering (Pandey & Pandey, 2012). 4. key process in requirement engineering Requirement engineering is a process which involves various of activities in order to achieve set targets. Whereas, in case of developing proposed app for the ABC ltd the process requires to follow steps requirement elicitation, negotiation, analysis and validation. Thus, required elicitation is useful for interpret, analyse and validate data from stakeholders. Requirement analysis helps in problem solving and reaching on an agreement by avoiding fixing conflicts. The needs and specifications have to be based on the documentation to avoid any clashes. also, Requirement validation is to make sure the process used is true, validated or correct and the requirement management process is to manage any required changes as systems can make errors (Pandey & Pandey, 2012). 4.1 Requirements of elicitation The requirement elicitation process is useful for discovering the needs and requirements of proposed app. This process makes sure to understand the clear needs of stakeholder in order to develop the proposed app different information and requirements should be gathered from the customers and trade persons as well (Yacoub, 2019)