Software Requirements Blog

I think in this class I have acquire a lot of knowledge of how to create a well written document for domain requirements in a Project. And is something that I do recommend to any software developer who want to do a large scale project. I think it is a necessary step in order to archive the goals of the project you want to create. It gives formalization and also a check list of things you need to have correct in order to give value to the client or the project.

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.

I learn that one way of creating a solution for a potential project or client is: Do Domain Acquisition by doing domain research, talking with domain experts, doing questionnaires. Then after having all that information you need to create a project definition. One of the ways I learn to do a project definition is by doing an Informative Documents that contains: Name of the project, place of execution and date, the need of the application, the idea of what the project going to do, the concepts and assumption you are making in order to complete the project, decencies and some goals. You can go and do some listening of requirements stakeholders: the people involve in these requirements that you going to do next. After having the stakeholders is good to group them by groups. Then you create the Requirements prescription units: that involves creating the requirement statement, the group of stakeholder involve in the requirement, and the concepts type and facet involve in it. Then a

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.

It is really important to do distinction between Verification and Validation. Verification is mostly verifying that your implementation is following the requirements that the software team made by doing domain acquisition and talking to the domain experts. Validation in the other hand, is when you go to the Domain Expert and show them the product and they approve that is right or wrong. Obviously that is a really general description, but it is essentially that. The funny story is, that most people would think that something as simple as that is not useful in real life. But for me, and many other, in some interviews with some companies, they ask about that and it is really useful.

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.