Why Model

The model specifies what a system does and how it does it.  Logically, therefore, one starts modeling by deciding what the system is going to do.  In traditional, document-driven development, one starts with a Request for Proposal (RFP) or Statement of Work (SOW), writes a proposal or System Specification Design Document (SSDD), writes the System Requirements Specification (SRS), and finally writes a System Design Document (SDD).  This methodology has worked for the last 50 years and I'm not suggesting that modeling should replace it.  For one reason, many contracts require text deliverables.  Rather, modeling augments this process.
Text is a very poor way for engineers to communicate.  For the most part, engineers are visual people.  If I were to ask you to go to whiteboard and describe the system you are currently working on, odds are pretty good that you will not write a bunch of paragraphs.  You will draw some circles and boxes and maybe some arrows to describe the flow.  In fact, the main reason we text documents to communicate is because computers come with keyboards.
Another problem with text is that words have different meanings in different industries and different parts of the country.  Take the word "fixing."  It might mean repairing.  Or, especially around the holidays, it might refer to side dishes.  Here in Fort Worth, Texas, it means you are getting ready to do something.
Not only do words have shadow meanings, but not all of our coworkers are native English speakers.  We may work with colleagues overseas.  More likely, at least one team member grew up speaking a language other than English.
Another problem with text-based requirements is how we were all taught to write.  Each of us had a high school English teacher, for me it was Miss Feage, who said "vary you sentence structure" and "use descriptive verb." While this advice applies when writing the Great American Novel, it does not apply when writing the Great American Requirements Specification.  For a requirements specification, we expect "subject shall requirement."  Unfortunately, I have yet to see a customer document written in this format.
Building specifications in UML and SysML avoid all of these problems.  UML and SysML are graphical languages.  Engineers and Computer Scientists relate better to diagrams than to text.  Furthermore, the graphics help engineers see the part of the system under consideration in a single view.  This view helps them identify missing exception conditions and inconsistencies. 

UML and SysML have very distinct syntax.  This syntax is designed to specify structure, interaction, and behavior in a distinct manner that, if used properly, is not open to misinterpretation.  And when it comes time to generate the deliverable documents, the better modeling tools support generating the documents directly from the model.
Bottom line:  modeling is more natural than text, will help you avoid and identify errors earlier, and still lets you follow your existing processes.