This week, I learned about requirements engineering and software architecture. The specific content is as follows:
First, requirement engineering collects software requirements from stakeholders and analyzes and records them (Marsic, 2012). Its ultimate goal is to form a specification document that describes the system (Marsic, 2012).
Second, requirement engineering includes requirements gathering, requirements analysis and requirements specification: requirements gathering is also called requirements elicitation, which means obtaining the requirements from stakeholders (Marsic, 2012); requirements analysis involves refining and reasoning requirements received from customers (Marsic, 2012); requirements specification represents a formal or semi-formal problem statement describing the capabilities, qualities, and constraints of the system-to-be (Marsic, 2012).
Third, requirements include functional requirements and non-functional requirements: Functional requirements are related to the functions and functionality of the system (Marsic, 2012), such as the search function of an application; non-functional requirements describe the quality characteristics of the system (Marsic, 2012), such as security.
Fourth, software architecture provides an abstract framework for the system, a series of principles focusing on the highly influential and high-priority aspects (Microsoft, 2009). It is generally after requirements analysis and before detailed design (Traore, 2006).
Fifth, there are many common architectural styles: Client/Server, Component-Based Architecture, Domain Driven Design, Layered Architecture, Message Bus, N-Tier/3-Tier, Object-Oriented, and Service-Oriented Architecture (Microsoft, 2009). In the actual development process, a system may use a single architectural style or combine some architectural styles (Microsoft, 2009).
Additionally, in the discussion forum, I elaborated on the strengths and weaknesses of developers and users in the requirement elicitation process. First, the main strength of users is that they know more business background knowledge and can help decide which requirements are needed or not. Their main weaknesses are that not all users can clearly express their needs, and it isn’t easy to maintain enthusiasm to interact with developers during the development process. Second, developers’ strengths are good computer skills to develop systems, such as choosing appropriate software architecture, data structures and algorithms. Their weaknesses are the lack of knowledge about the problem domain, which may hinder them from understanding users’ needs.
Furthermore, in the programming assignment, I judged whether some requirements could be verified and wrote acceptance tests for those testable requirements. Acceptance tests specify the conditions under which user requirements are passed and those under which requirements are rejected. It is worth mentioning that the prerequisite for writing an acceptance test for a requirement is that the requirement is testable. In other words, the requirement cannot contain some subjective or vague expressions, such as “the system should be easy to use” (Marsic, 2012, p. 76).
Finally, one important thing I want to do is to learn software architecture styles in depth because understanding the usage scenarios, advantages and disadvantages of these styles is crucial to software development. For example, the Layered Architectural Style has the characteristics of high cohesion, loose coupling, and Isolation (Microsoft, 2009). Therefore, if the application is complex and the high-level design needs to be separated, developers can choose this architectural style so that the team can focus on different functional fields (Microsoft, 2009).
Word count: 508
References
1.Marsic, I. (2012). Software engineering. Rutgers Unversity.
http://www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdf
2.Chapter 3: Architectural patterns and styles. (2009). Microsoft.
https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658117(v=pandp.10)
3.Traore, I. (2006). Chapter 1: Introduction to Software Architecture. The University of
Victoria.
https://www.ece.uvic.ca/~itraore/seng422-06/eng422-06.html