An important component of this unit’s reading that stood out to me was the process in which the requirements definition is to be curated. By definition, the requirements definition identifies the business requirements of the system in development. This includes what the system is to do, how users will interact with it, the conditions in which the system is to operate, and any criteria the system should meet. CISA outlines the methodology for completing the requirements definition phase. This includes consulting stakeholders to gage their requirements, analyzing requirements against expectations, converting user requirements into system requirements, and resolving any conflicts that present themselves. The process also includes instructions on documentation. I found it interesting how interactive this process is with various stakeholders and steps involved. User management, system developers, user departments, and other management personnel are involved in this process. This is essential to ensure the requirements definition is as comprehensive and thought-out as possible. I believe this is an important component in the development phase that needs to be as interactive as possible. If this were to be one-sided, or if certain stakeholder groups were excluded, the business requirements would be severely incomplete, which would damage the entire development process.
Heather Ergler says
This week’s reading is focused on the requirements gathering phase of SDLC projects. In particular the reading focused on different methods used to gather requirements from traditional to contemporary to radical to Agile methodologies that combine the various methods. What I found interesting was that regardless of methodology, documentation and information around how the team developed and implemented the requirements seemed to be a consistent weakness in all the methods. Having been part of a requirements gathering team for the last 30 years, I find that no matter how well a team documents their decisions and requirements, the documentation has a single weakness in that only the team that developed the documentation actually understands its meaning. So I personally have been a fan of only using system schematic diagrams to describe how the system operates inclusive of data flow diagrams and process workflow documents to describe how users interact with the system. The visual depiction of a system and the processes around the system are more timeless and resource dependent than text requirements.
Zibai Yang says
SDLC is the software development life cycle. The software life cycle is the life cycle from the software product to the end of life. There are problem definitions, feasibility analysis, overall description, system design, coding, debugging and testing, acceptance and operation, maintenance and upgrading to Abandonment, and other stages. This time-based thinking method is a principle of thinking in software engineering, step by step, step by step. Each phase must be defined, worked, reviewed, and formed documents for communication or reference. Improve the quality of the software. But with the maturity of new object-oriented design methods and technologies, the guiding significance of software life cycle design methods is gradually decreasing.
The development of the software life cycle model actually reflects the development of software engineering theory. In the earliest days, the life cycle of software was in disorder and chaos. To control the software development process, some people strictly divide the software development into multiple different stages and add strict inspections between the stages. This is the cause of the waterfall model. The waterfall model reflects people’s hope for the software process: strict control and quality assurance. Unfortunately, the reality is often cruel. The waterfall model cannot meet this high requirement because the software process is often difficult to predict. Instead, it led to other negative effects, such as many documents and cumbersome approvals. So people began to try other methods to improve or replace the waterfall method. For example, the process is subdivided to increase the predictability of the process.
Priyanka Ranu says
This week’s reading focused on the requirements gathering in the SDLC phase. There are different methods which are traditional, contemporary, radical, agile. The common factor among these methods is communication with various people involved such as users, stakeholders, managers etc. directly or indirectly and affected by the possible system changes. Talking to people involved is the best way to collect information about the information systems that are currently being used and how users would like to improve the current systems and organizational operations with new or replacement information systems. The contemporary method that stood out to me is joint application design (JAD). One of the advantages of this method is reduced time because the user and other key members are heavily involved in the process which is highly effective. Another point to note is that JAD sessions are conducted at a location other than the normal workplace which helps in reducing distractions so the participants can focus on systems analysis. The participants involved are: JAD session leader, users, managers, sponsor, systems analysts, scribe, IS staff. The end result of the JAD is usually a set of detailed documents that highlights the workings of current system related to the study of a replacement system.
Elias Harake says
In this week reading of Chapter 7 in our textbook, I thought it was interesting to learn how to model and analyze 2 important views of an information system, which are the flow of data between manual or automated steps as well the decision logic of processing data. I also learned how to show data stores, or data at rest, in a data flow diagram (DFD). DFDs use cases and various processing logic techniques show how, where, and when data are used or changed in an IT system. However, these techniques do not show the definition, structure, and relationships within the data. Data modeling develops these missing and descriptive pieces of a system.
Data captured during data modeling are crucial in the design of databases, programs, and printed reports. data, not processes, are the most complex aspects of many information systems. Therefore it requires a central role in structuring system requirements. Transaction processing systems can have complexity in validating data, reconciling errors, and coordinating the movement of data to various databases. Perhaps this is why Bitcoin and other blockchain systems are gaining interest by even some reputable companies such as Tesla.
Jonathan Mettus says
When I first started reading the chapter, I thought about a phrase a friend of mine always uses: “paralysis by analysis.” Sure enough, the textbook brought up the idea of analysis paralysis. Too much analysis in the requirements gathering phase can stall the project. It seems to me, upon reading more about the more modern methods, that there’s now an emphasis are keeping analysis to a minimum, but making it effective. JAD, prototyping, and things like Agile use high user involvement throughout the process.
Haozhe Lin says
For this week’s reading, I am most interested in the phase of SDLC projects. Software Development Life Cycle is the application of standard business practices to building software applications. It’s typically divided into six to eight steps: Planning, Requirements, Design, Build, Document, Test, Deploy, Maintain. Some project managers will combine, split, or omit steps, depending on the project’s scope. These are the core components recommended for all software development projects.
SDLC is a way to measure and improve the development process. It allows a fine-grain analysis of each step of the process. This, in turn, helps companies maximize efficiency at each stage. As computing power increases, it places a higher demand on software and developers. Companies must reduce costs, deliver software faster, and meet or exceed their customers’ needs. SDLC helps achieve these goals by identifying inefficiencies and higher costs and fixing them to run smoothly.
Priyanka Ranu says
Hi Haozhe,
SDLC is important for developing a software system as it offers a basis for project planning, scheduling, and estimating. It provides a base or framework for standard set of activities and deliverables. Most importantly it helps to reduce project risk.
Cami Chen says
In this week’s reading, it is fucus on the requirements of a structured system process, and the goals for these requirements are aligning business strategies and IT strategies. I want to point out is that the differences between a use case diagram and a written description of a use case. First, the use case diagram provides a very brief of the main points of the system for the users, and it is easy to understand the main ideas of specific events and the relationship of every event. However, it does not describe the details of each event implementation. Even though the use case diagram does not like an essay, it provides a very clear outside view of a system for both internal and external users. In contrast, a written description of a use case is documentation, and it is a supplement, which provides the details of each event. It supports the use case definition, and it explains how each event will implement, and what the users should pay attention to. Also, it will tell the users step by step what and how they should do. Therefore, the written description of a use case expands the use case diagram as a guideline to tell a story to the users.
Shaneil Wilson says
In this week’s readings, I gathered that the analysis phase has two subphases: requirements determination and requirements structuring. In the traditional requirements determination interviewing, observing users in their work environment, and collecting procedures and other written documents are done. However, the use of current methodologies has taken over and have proven somewhat I think more efficient in determining requirements. This includes Joint Application Design (JAD) and prototyping. Requirements analysis allows systems analysts to construct a more condensed and tailored list of system development requirements from high-level explanation. A lot of information is needed to achieve this however, too much information could hinder the structuring phase. Because of the dangers of excessive analysis