Diagrams

Something that is really good to express how requirements are applied into designing a project is by creating diagrams. Here are some of the diagrams I learn from the software requirements class, that I think are really useful for any software project:

  • Problem diagram: Better for expressing interaction between system scope like context and problems.

  • Entity relationship diagram: Better for modeling a database but basically for conceptual structures.

  • SADT diagrams with actigram and datagram: When it comes to activities like input and output, and how the environment can affect those values.

  • Event Trace diagram: Interaction between all the scenarios that can be in your program.

  • State Machine diagram: For system behavior such as how the program operates and all the possible outcomes.

Comentarios

Publicar un comentario

Entradas populares de este blog

Domain Acquisition, Analysis, Concepts Formation

Domain Acquisition: One of the main way I learn about software acquisition is that it is useful to look for feedback on people who works with the domain, and one way of acquiring this feedback is by doing questionnaire. As a software developer who is in charge of looking for domain information you need to do a paper with question in order to get main info about the domain. Domain Inconsistencies: Many of the way to describe something in the domain is by doing domain prescription units, but when you do them it could lead to some inconsistencies. That is why you must look for inconsistencies and most of them are visible by looking for something that is the opposite of what a prescription unit is saying. Domain Concepts: Something that you can see, in domain prescription units are concepts. This concepts can be words and terms that can be get from those prescription.
Leer más

Class Review

Positive: Requirements Topics Emphasis on the different types of diagrams Take home exams, instead of 2 hours non stop writing in a rock chair like in software engineering. Recommendations: Keep this method of exams to the other student in future classes, as you may have read, my back was killing me back when I took software engineering because the classroom and their chair were really uncomfortable to me. These exams have a lot of content so you are basically non stop writing, but in your house is better to do it. I am still not a fan of Bjorne books (same as in Software Engineering) not because of the content, but because of his writing, sometimes it is difficult to understand what he is trying to do or deliver. But that is just a personal opinion. Maybe changing one partial exam in the semester with a project involving requirements documents, like in the Design Class.
Leer más

Good thing about knowing SR

This month I had an interview with this company called Accenture and basically is a consultant company. So everything I learn from this class can be applied to that company. why? When you need talk to a customer who wants to create an application, you need to do software requirements and by that you need to do all what I learn here from: - listing stakeholders - domain research - domain questionnaires - domain prescription units - domain concepts - domain theories But how did I benefit from that, in that company Accenture they do a case interview where you need to talk with a hypothetical customer who want to do an application, and you are a consultant. The interview problem is to see how you resolve and come with a plan to resolve the customer need and the best way of doing that, or thinking about a solution is by software requirements.
Leer más