I've been doing a Requirements Analysis module in my university. We've covered all kinds of formal requirements stuff, like UML, Use Case Diagrams, Sequence Diagrams and Contracts. I have to ask- are any of these things of any value whatsoever in the real world? The only Use Case Diagrams I've ever seen could be summed up in a vastly more succint and understandable way in plain English- or even code in a reasonable language of your choice- and the same goes for the other things I've mentioned.
Requirements analysis is a process that uses tools like UML diagrams.
Diagrams facilitate communication and sometimes can be used to generate code (e.g. 1 and 2 below). They also aid in adding a visual layer to the solution that could some time help the end users and developers (e.g. 4, 5 below).
Use Case diagrams represent high level view of the interaction and don't replace the textual case description.
Some of the very important diagrams for showing requirements and design are: 1. Entity relationship diagrams 2. Class diagrams 3. Sequence diagrams 4. BPM - Business Process Models 5. Page Flow diagrams 6. Use Cases
Requirements analysis is a large subject and may use other diagrams as well. The important thing is that you capture and communicate your knowledge about the system requirements to the developers and the end-users.
There are suite of tools that can validate some of the above diagrams (e.g. 1,2). Some tools can build a web applications automatically from (1 or 4).
Yes the diagrams are important and are used in some projects.
School problems are over simplified for learning. So you can't make any value judgements based on them as to the utility in the real world. Next most people who do requirements Analysis are NOT programmers and certainly could not express the requirement in code. Third, these are most useful when doing large complex projects, so the experience of people working on smaller things may indicate that they are less than useful where the experience of people working on space shuttle type projects might be different.
The last large project I worked on had an inital requirements document of over 800 pages (which grew to be much larger by the end) sometimes having a diagram makes it easier to understand the written word. It also helps to keep people things in terms of the process that needs to be created and helps prevent silliness such as requiring the software to have an approval from a manager fo rthe budget expenditure for a project of more than $1 million but no requirement that tells you what to do do if he rejects the project. When you use a structured approach, you are more likely to see all the pieces I think.
Are these techniques appropriate for all projects always, no of course not. Agile projects tend to take a less complex approach to begin with and these techniques might be perceived as time wasters. From what you wrote, I would suspect you are someone who is more comforatble with the agile approach and thus may not use these techniques or see them in the projects you work on. What is critical about learning them for you may be more the analytical thought process that goes into doing them rather than the actual diagrams themselves.
Yes, these things have value in the real world.
You don't always use all of them, and you don't always polish them to perfection, but they are all useful tools to model the problem domain and be sure you're going to build the correct solution.
Each of these artifacts exists because they are better ways of documenting what's going on than plain text. If plain English worked better, we'd use that. (Where plain English works better, we use do use textual requirements!)
Don't be fooled by the simplicity of these things in the learning environment. They can get quite complex in the real world. Or, alternatively, sometimes they are not complex -- and thus become a simple way of conveying understanding.